The Ten Pains of Unix Security. Learn How Privileged Account Security Solutions are the Right Remedy

Transcription

1 Learn How Privileged Account Security Solutions are the Right Remedy

2 Table of Contents Introduction: Control Access, Empower Teams 3 The Ten Pains of Unix Security 4 Pain No.1: Who Has Access to my Unix Environment? 4 Pain No. 2: SSH Keys: Privileged Access for Anyone 5 Pain No. 3: Uncontrolled Access to the Keys to the IT Kingdom 5 Pain No. 4: Sudo: An Illusion of Control 6 Pain No. 5: What Are My Users Really Doing? 7 Pain No. 6: Uncontrolled Third-Party Access 8 Pain No. 7: Are My Jump Servers Secure and Effective? 9 Pain No. 8: Vulnerable Hard-Coded and Locally Stored Application Credentials 10 Pain No. 9: There Are More Unix Identities Than I Can Manage 10 Pain No. 10: I Don t Know if my Accounts Have Been Compromised 12 CyberArk s Privileged Account Security Solution 13 CyberArk Software Ltd. cyberark.com 2

3 Introduction: Control Access, Empower Teams This whitepaper presents the security pains prevalent in Unix environments and offers some advice on what requirements to look for when evaluating solutions. The best remedies should help maximize control over Unix environments while still empowering IT teams to be effective and productive. Back to Basics: The Role of Privilege Typical enterprise IT environments are comprised of hundreds or thousands of servers, databases, network devices and applications, all controlled and managed by a variety of privileged and shared administrative identities. Privileged user accounts are the most powerful accounts in any organization, yet these identities are often shared between many users, and their credentials are rarely changed. Privileged accounts include root accounts on Unix/Linux, administrator on Windows, enable on Cisco systems and many more. Put simply, the privileged administrator role gives users the power to configure virtually every aspect of a system. These superuser accounts and users with these administrative privileges can access your most sensitive data and perform operations on your most critical systems. In the wrong hands, mismanaged privileged accounts pose devastating risks to organizations, including lost revenue, reputational damage and regulatory penalties. Whether the damage is intentional or accidental, initiated by an outside or insider, the risks associated with unmanaged privileged accounts are the same. To effectively protect the enterprise, organizations must enforce individual accountability, proactively control access to privileged accounts, and limit administrative privileges. Organizations must also be able to rapidly detect unauthorized or suspicious activity that could signal an attack. To achieve these critical detection capabilities, organizations must proactively monitor, record and analyze all privileged activity. CyberArk Software Ltd. cyberark.com 3

4 The Ten Pains of Unix Security Unlike Windows environments, which are centrally managed and contain a mix of privileged and business users, Unix environments consist of tens or hundreds of disparate systems that are accessed solely by privileged users. While many organizations take steps to protect the root user accounts on these systems, the numerous individual user accounts that are able to gain root privileges are often overlooked by security teams. Due to the decentralized nature of Unix systems, it is incredibly difficult for security teams to know exactly who has access to what. Without this baseline visibility, it is can seem impossible to enforce controls that limit user privileges and monitor activity. As a result, Unix users are often able to gain uncontrolled root privileges, leaving the organization vulnerable to both malicious and accidental damage to critical systems. This document sheds light on some of the more prominent pains associated with securing Unix environments and offers advice on how Privileged Account Security is the right remedy. Pain No.1: Who Has Access to my Unix Environment? In Unix environments, it can be very difficult to determine how many users have access to root accounts or how many accounts have root privileges. Without this basic, baseline information, the idea of proactively securing privileged accounts can seem near impossible, and for many organizations, such a project would be considered too difficult to take on. The trouble is, accounts with root privileges are incredibly powerful and can be used to damage critical systems, exfiltrate sensitive data or simply advance the reconnaissance phase of an advanced attack. In today s threat environment, as attackers become more sophisticated and determined, organizations can no longer afford to do nothing. Before organizations start considering ways to proactively protect privileged Unix accounts, they must first understand the current state of the environment. While this can sound like a daunting task in disparate Unix environments, with the right tools, this can process can be automated and simplified. Organizations should look for tools that: Discover all privileged accounts that exist on their systems Locate all privileged credentials, including both passwords and SSH keys Map trust relationships between users and systems Using this information, organizations can determine which accounts exist, which accounts are authorized, and what privileges are associated with each account or credential. This data can also be used to understand system relationships and uncover ways in which an attacker could laterally move throughout an environment. Armed with privileged account insights, organizations can create an actionable plan to take control of privileged accounts, restrict privileged access and minimize risks within their Unix environment. CyberArk Software Ltd. cyberark.com 4

5 Pain No. 2: SSH Keys: Privileged Access for Anyone SSH keys are commonly used to establish trust between systems and encrypt communications between those trusted systems. In the right hands, SSH keys are valuable tools used to facilitate strong authentication and secure transactions, but in the wrong hands, they can be used to grant malicious users direct, secretive access to critical systems and sensitive data. The trouble is, most organizations have no way to determine how many SSH keys exist, which users and applications have access to those keys, or if those users or applications are, in fact, authorized to access target systems. As a result, malicious users inside a network can utilize SSH keys to grant themselves permanent privileged access to systems that contain highly sensitive data, and security teams would likely never know. Worse, these malicious users can exfiltrate sensitive data without setting off alarms, thanks to the encrypted SSH tunnel. To gain visibility into the current state of the Unix environment and take back control of SSH keys, organizations should: Discover all SSH keys within their environment. Use a tool that can find all SSH keys within the environment, map SSH key pairs and uncover orphan keys. Remove unknown, unnecessary keys. First remove all orphan keys, which may be providing backdoors into critical system. Next, evaluate trust relationship in accordance with organization policy, and remove all keys that provide users with unauthorized or unnecessary privileges. Lock down the authorized_keys file on all machines. Review and update system settings to ensure that only the root account has write access to the authorized_keys files. By locking this down, only root users will have the ability to add public keys to a system, thereby preventing new instances of unauthorized access to critical systems. Securely store authorized private keys in a central, controlled location. Remove private SSH keys from endpoints to reduce the risk of theft and unauthorized credential sharing. Instead, consider storing these private keys in a highly secure, central location, to which security teams can enforce access controls and strong authentication. By taking these steps, organizations can remove backdoors into critical systems and drastically reduce the risk of new backdoors being created in the future. These steps also reduce the risk of compromised SSH keys, which can be exploited by malicious users to breach systems and steal valuable data. Pain No. 3: Uncontrolled Access to the Keys to the IT Kingdom Given the superuser privileges associated with root accounts, the credentials used to access these accounts are, in essence, the keys to the IT kingdom. With these keys, any user authorized or not can make changes to critical systems, alter files, access sensitive data and more. In the wrong hands, the damage done could be catastrophic to the IT environment and the business. To mitigate this risk, organizations should secure, manage and control access to the credentials used to access not only root accounts but also user accounts that contain root privileges. The trouble is, due to the decentralized nature of Unix environments, this can be incredibly difficult and require significant operational effort if the right tools are not used. First and foremost, organizations should seek solutions that can centrally manage privileged accounts across a variety of platforms, including but not limited to Unix systems, Windows systems, databases, network devices, mainframes and cloud environments. Security teams should seek solutions that can proactively secure, manage and control access to privileged account credentials in an automated way, so as to not put undue burden on the security team. To meet these security and operational requirements, security teams should seek solutions that: CyberArk Software Ltd. cyberark.com 5

6 Protect unauthorized access to privileged account credentials. Store all privileged account credentials, including both passwords and SSH keys, in a highly secure centralized repository that supports strong authentication and access controls. Proactively rotate privileged account credentials. Implement solutions that can automatically rotate credentials throughout the entire environment either at a regular cadence or on-demand. Reduce the use of shared accounts, and enforce the principle of least privileges. Minimize the use of shared administrative accounts, and instead require users to use individual accounts with limited privileges for every-day use. Complement this with tools that enable privilege escalation for approved business purposes only. Hold individuals accountable for shared account usage. When shared privileged accounts are necessary, require individual users to check-out the shared credentials as needed to perform required tasks. Audit privileged user activity. A good solution should enable centralized, easy reporting that clearly shows exactly who did what and when. By following these recommended guidelines, organizations can reduce the risk of unauthorized access to privileged credentials, limit the damage an attacker can cause while using a compromised credential, discourage authorized insiders from abusing privileges, and prove compliance with security and regulatory requirements. Pain No. 4: Sudo: An Illusion of Control Beyond protecting the Keys to the IT Kingdom in a centralized manner, organizations must also limit the privileges associated with these privileged credentials. To prevent intentional or accidental damage to critical systems, organizations need a way to enforce the principle of least privileges. Some organizations have attempted to solve this pain using sudo. However, sudo presents challenges of its own. As an open-source, imperfect solution, sudo can present significant security, compliance, scalability and reliability challenges, particularly in large IT environments: False sense of security. Many organizations adopt allow-all policies, meaning that users can invoke sudo for any reason, to run any command, without any restrictions. When organizations do attempt to restrict privileges, sudo policies must be stored on the local file system, which privileged users can access and modify without leaving an audit trail. Difficult to pass compliance audits. Sudo logs present several challenges and often times leave auditors with an incomplete, insufficient, and potentially tampered-with audit trail. These challenges include: o Limited logs. Sudo will typically log that a user ran the sudo command, but it does not always show what subsequent commands were run during the superuser session. Further, commands executed in certain shells cannot always be documented. o Editable audit trails. When activity is documented, the logs are written to local files, which users are able to access and potentially alter. o Manual reporting. To compile a full audit report, administrators must first correlate logs across all systems. This can result in human error leading to inaccurate audit trails. Siloed approach is not enterprise scalable. As an inherently local solution, sudo policies cannot be centrally managed across systems. In large enterprise environments with hundreds of Unix servers, the operational effort required to manage sudo is significant and oftentimes not feasible. Challenges with reliability. As an open source solution, there is no support center to contact when a problem is encountered. When something goes wrong, organizations can face significant downtime and lost productivity until a suitable resolution is found. CyberArk Software Ltd. cyberark.com 6

7 Organizations not using sudo or a sudo alternative are often forced to resort to shared root accounts. When root accounts and their credentials are shared among members of the IT team, security teams have no way to limit or monitor individual user privileges. Worse, shared accounts can easily be shared with unauthorized users without the security team ever knowing. Regardless of whether an organization is using sudo or simply relying on unmonitored shared accounts, neither option is sufficient for managing privileges in an enterprise IT environment. Each choice carries major tradeoffs between security and usability, and neither offers a way to meet and prove compliance with security and regulatory requirements. To effectively address the need for least privileges, organizations should seek scalable, centralized solutions that effectively balance security and productivity requirements across the IT environment. Such a solution must also offer centralized reporting to help organizations meet audit requirements. To remain productive, users should have the privileges necessary to complete their day-to-tasks, but for security purposes, they should not have excess privileges. Security teams should seek solutions that support the least privilege principle by enabling security teams to write privilege policies based on user or user group. Such policies should: Define administrative privileges that a given user should always have Define elevated privileges that a user can automatically receive on-demand for valid business purposes Require approval workflows that must be completed before a user may access root privileges In the infrequent event that a user needs full root access to complete a task, users should be able to request this access in a simple, auditable way. A good solution should support automated approval workflows through which users can submit their requests to a manager, system owner or business owner, and only upon receiving the required approvals should the user be able to access root privileges. For added controls during elevated sessions, all user activity should be tracked on a separate system that users are unable to access or alter. Further, users should be informed that their activity is being tracked. This additional oversight not only provides the tamper-proof reporting needed for security and compliance audits, but it also serves to discourage users from misusing these elevated privileges. Pain No. 5: What Are My Users Really Doing? Basic audit logs are a good way to document events on systems, but they can be difficult to review and fully understand. For security and compliance reasons, it is important for organizations to have comprehensive recordings of privileged activity that can easily be searched during an audit or incident investigation. Without a comprehensive, searchable audit trail, security teams can waste hours digging through irrelevant data while trying to determine how an event started and how it should be fixed. Compounding this issue, in traditional Unix environments only basic events (e.g. login, logout) are recorded, and these logs are stored locally on individual machines, meaning security teams must first collect the logs before being able to analyze them. In the case of a malicious attack in progress, the hours spent manually finding and reviewing logs can mean the difference between a stoppable breach and the complete exfiltration of data. Similarly, in the event of accidental damage by an authorized user, wasted hours can result in excess downtime of critical systems, lost productivity and, in some cases, lost revenue for the business. To better understand what users are doing during privileged sessions, shorten audit cycles, and accelerate incident response times, organizations should seek solutions that offer: CyberArk Software Ltd. cyberark.com 7

8 Centralized audit of session activity. All session history across the enterprise should be available from a single location that is easily accessible by authorized auditors and incident responders. Real-time session monitoring. Security teams should have the option of monitoring privileged sessions in real-time to give them the opportunity to instantly detect suspicious activity. Security teams should also have the ability to remotely terminate high-risk, suspicious sessions. Searchable audit logs and video recordings. To accelerate investigation and response times, teams should have the ability to search audit logs to quickly locate the instant something went wrong. Tamper-proof audit logs. To ensure that security and audit teams have the full picture of what happened, organizations must securely store session history and audit logs and ensure that users are unable to manipulate these records. By gaining a complete, tamper-proof, and searchable history of all privileged session activity, security teams can rapidly detect and respond to incidents within the Unix environment, and organizations can easily meet and prove compliance. Pain No. 6: Uncontrolled Third-Party Access In today s interconnected environment, organizations must often grant privileged access to third-party users. From vendors managing specific systems to cloud service providers maintaining virtual datacenters to consultants working on contracted IT projects, it is not uncommon for a large number of outside users to have legitimate, privileged access to critical systems. The trouble is, to enable this third-party access, organizations must often share superuser credentials with their outside vendors, yet they have little or no control over how those vendors secure the credentials or control their users. Making matters worse, targeted attackers today are savvy and willing to breach any organization that could provide direct access into the end target. Too often, third-party vendors with privileged access are the middle-man of choice due to their less stringent security practices. In fact, third-party vendors have been the initial point of compromise in several recent high profile data breaches. Despite this known vulnerability, organizations struggle to defend this attack vector because, ultimately, they have little control over security practices at their business partners. To effectively defend this attack vector, organizations must first determine which outside parties have privileged access and what levels of privileged access they have. Organizations should next put proactive controls in place to secure and monitor third-party access to critical systems. Suggested best practices include: Enable privileged single-sign on. Privileged single-sign on enables organizations to provide the privileged access needed while preventing third-party users and their machines from ever knowing root credentials. To accomplish this, organizations should authenticate individual users once, then transparently open privileged root sessions on target systems. Isolate privileged connections. Secure jump servers should be used to separate end users from target systems. By isolating these connections, organizations can prevent malware from spreading from infected end user machines to critical target systems. Enforce access controls on target systems. Consider locking down target systems so that they may only be accessed via dedicated jump servers. This strict access control adds an extra security layer, ensuring that no one may directly access systems. Monitor and record everything. To help pass audits and rapidly investigate security incidents, organizations should monitor and record all privileged session activity. By implementing these recommendations, organizations can dramatically reduce the risks associated with third-party access and gain a full audit trail of all third-party activity. Using this data, organizations can ensure that third-party users are not abusing privileges, prevent targeted attackers from exploiting third-party access, gain the data needed to rapidly investigate and respond to incidents, and meet security and audit requirements. CyberArk Software Ltd. cyberark.com 8

9 Pain No. 7: Are My Jump Servers Secure and Effective? Jump servers are commonly used in Unix environments to separate vulnerable end user machines from sensitive target systems, prevent the spread of malware and stop lateral movement between systems. However, all too often jump servers are improperly secured or controlled, rendering them ineffective for protecting critical systems. Without the proper system configurations and controls, organizations can face several risks, including: Spread of malware to critical systems. Without the proper controls, jump servers can facilitate the spread of malware from infected end user devices to critical target systems. Direct access to critical systems. Without traffic restrictions on target systems, users authorized or not can bypass jump servers to gain direct access to critical systems. Exploits against jump servers. In an unsecured state, advanced attackers can exploit jump servers to steal the private SSH keys and hard-coded passwords that are used to transparently access target systems. With these credentials in hand, attackers can move to critical systems. To ensure the security of the systems that sit behind jump servers, organizations must properly configure these assets. To accomplish this, organizations should: Lock down jump servers. Treat all users on jump servers as underprivileged users, and restrict the commands and tools that may be run on these machines. Use dedicated, hardened machines to ensure that only authorized, trusted software is able to run. By locking down these machines, malware from an infected end user device will be unable to spread via the jump server to the target system. Remove hard-coded passwords and SSH keys from jump servers. Remove all hard-coded passwords and locally stored SSH keys from jump servers to reduce the risk of these credentials being compromised by attackers on the inside. Instead store these credentials in a centralized, secure location, and only retrieve them as needed to initiate connections. Mask all target system credentials. Securely store target system credentials in a central location, and enable privileged single sign-on for authorized users. This masks target system credentials from users and their machines, thereby preventing lateral movement and ensuring that users are unable to bypass jump servers and access critical systems directly. Restrict traffic to the target systems. To ensure that no one authorized or not is able to bypass jump servers, consider restricting traffic into the target systems. Either use network segmentation and separation (e.g. firewalls) or configure target systems to only allow incoming traffic from specific, secure jump servers. This prevents users from directly accessing target systems, and it enables organizations to enforce access controls and strong authentication on the jump servers before establishing privileged connections. By implementing these recommendations, organizations can effectively secure their jump servers, better protect their critical systems and ensure that all privileged traffic must pass through these servers before establishing connections with target systems. In this improved state, organizations can begin leveraging their secure jump servers for added capabilities. Once secured, jump servers can act as a single point of control, enforcing policies regarding who can access what systems, as well establish a single location from which security and audit teams can monitor privileged session activity. CyberArk Software Ltd. cyberark.com 9

10 Pain No. 8: Vulnerable Hard-Coded and Locally Stored Application Credentials In today s complex IT environment, multiple scripts, processes and applications need to access resources such as databases, directories, FTP servers and more. To facilitate this access, passwords are often embedded in clear text within application code, scripts, and configuration files, and SSH keys are stored locally on each machine, ready to be called as needed for authentication. These privileged passwords and SSH keys are visible to developers, DBAs, IT personnel and anyone authorized or not who is inside your network. Yet, despite this built-in risk, many organizations are hesitant to strengthen application security at the risk of negatively impacting mission critical systems. As a result, plain text credentials leave service accounts, applications and mission critical systems vulnerable to compromise. When looking to strengthen application security, organizations should assess solutions that eliminate hard-coded and locally stored plain text credentials without introducing operational risk to mission critical systems and applications. Key requirements should include: Secure storage of application credentials. Remove embedded passwords and locally stored SSH keys from applications and application servers. Instead, store these credentials in a secure, central repository, and retrieve them only as need for authentication. Centralized credential management. Organizations should be able to set and manage application credential policies from a single location. Such policies should dictate which applications may use which credentials and how frequently credentials must be rotated. Automated credential rotation. Automated password and SSH key rotation enforces organizational policy without introducing the unnecessary risk of human error. Strong authentication of applications. To protect against spoofed, malicious or unauthorized applications, organizations should authenticate all applications requesting a privileged credential based on their characteristics, such as path or signature, before providing the privileged credentials. High availability to ensure business continuity. Any application security solution must be able to improve security without introducing any added risk of downtime. Organizations should ensure that credentials for mission critical and business critical applications are always available, even in the event of network outages. By implementing these recommendations, organizations can strengthen application security and meet compliance requirements without introducing operation risk to high-value critical systems. Pain No. 9: There Are More Unix Identities Than I Can Manage IT administrators are tasked with provisioning new user identities, managing those identities as users move roles and deprovisioning those identities as users leave the organization and in Unix environments, administrators must do this all without any type of central management system. Because each Unix system operates as a silo, Unix users in large environments can have tens or hundreds of identities one for each account on each system they may access. Because of the operational burden on IT to manage these identities, it s not uncommon for their associated account credentials to remain static or for dormant users to have privileged access long after they should, introducing added security risk to the organization. To help reduce the burden on IT teams and simplify the management of Unix identities, some organizations have opted to go one of three routes. Yet, none of these options provides a complete, secure and cost-effective solution: CyberArk Software Ltd. cyberark.com 10

11 Shared accounts. To avoid the provisioning and deprovisioning of individual user identities, some organizations have opted to create shared accounts, which can be used by multiple members the IT team. The trouble is, there is no way to know exactly who has access to these privileged credentials, and there is no way to track who did what during a privileged session. In addition, static shared account credentials can leave former employees with permanent privileged access to critical systems. Network Information Service (NIS). While NIS was, at one time, a helpful tool for administering Unix systems, it is simply not able to scale to the needs of today s large, complex enterprises. Among other challenges, NIS is incredibly complicated to manage, requires duplication of the LDAP repository, and requires two different sets of user credentials. Identity and Access Management (IAM) solutions. Some organizations invest in IAM solutions to manage the provisioning and deprovisioning of personal user identities in Unix environments. However, these solutions can be extremely complex, and organizations often find it very difficult to implement and deploy the workflows needed to manage their Unix user identities. AD Bridge. AD Bridge solutions enable the central management of Unix users in Microsoft AD, as well as authentication to Unix systems using AD credentials. Despite the benefits, AD Bridge solutions lack provisioning capabilities and can carry hefty acquisition and administrative costs. Of the three options outlined above, AD Bridges are often the best choice. However, these solutions can carry high costs and require significant administrative oversight. A better approach is to find alternative ways to achieve the most valuable AD Bridge capabilities without investing in an entirely new, expensive solution. Organizations should look for lower-cost solutions that support: AD authentication to Unix systems. Consider solutions that enable AD authentication to Unix systems to reduce the total number of credentials that must be managed. Such functionality also improves the user experience by reducing the number of credentials users must remember. Auto-provisioning and deprovisioning. Look for solutions that support automated provisioning and deprovisioning of Unix accounts, as defined in AD. As new users are added to Unix groups in AD, the appropriate Unix accounts should be provisioned accordingly as users require access. Similarly, as users leave the organization, a deprovisioned AD identity should flow through to associated Unix systems. Centralized group policy for Unix users. Organizations should look for solutions that centrally manage policies for all Unix users. With this capability, administrators can easily add or remove account permissions as users change roles, as business groups restructure or as policies change. Centralized reporting of Unix login activity. Administrators must be able to report on user groups, individual users and privileged user access. Organizations can use these reports to prove compliance during audits as well as investigate suspicious login activity. By implementing these recommendations, organizations can reduce the total number of passwords and SSH keys in the environment, thereby reducing the attack surface. Organizations can also better protect valuable AD credentials and gain operational efficiencies by managing all user identities for both Windows and Unix from a central location. CyberArk Software Ltd. cyberark.com 11

12 Pain No. 10: I Don t Know if my Accounts Have Been Compromised One of the biggest challenges facing organizations today is how to determine if something has been compromised. Research shows that attackers are inside a network, on average, for 229 days before they are discovered. 1 This means that attackers have nearly eight months to traverse the network, locate sensitive data and steal it before they are discovered; and they are able to do this because they are disguised as real users and real privileged users that can hide in plain sight. In this threat environment, the goal must now be to detect attacks as quickly as possible and minimize their potential damage. The trouble is, without meaningful data, this is near impossible. Today, security teams are bombarded with thousands of alerts each day, and with too much data, too much incomplete data and no tools to automatically prioritize this data, finding the signal in the noise is near impossible. To gain the upper hand against cybercriminals, organizations must gain advanced detection capabilities based on behavioral analytics that not only find suspicious activity, but also prioritize the risks for security teams. Organizations should look for tools that: Capture meaningful data from Unix systems. Native Unix logging tools provide an unreliable and incomplete history of privilege account activity. Therefore, the first step towards gaining better data is to implement a tool that can log all privileged account activity and store it in a tamper-proof central repository. Analyze privileged user behavior. Leverage tools that analyze and learn privileged user behavior over time. Using this baseline information, such tools should be able to detect anomalous user activity that could signal an inside attack or a compromised privileged account. Analyze privileged account behavior. Because the behavior associated with privileged accounts typically does not often change, any abnormal activity could signal an attack in progress. As such, it is important to monitor privileged account activity both independent of and correlated with privileged user activity to rapidly detect anomalous events. Prioritize alerts. After correlating privileged user activity and privileged account activity, a good behavioral analytics tool should prioritize threats based on their severity so that security and incident response teams know what to investigate first. Any anomalous activity on privileged accounts should take first priority for security and incident response teams, as privileged accounts are the last line of defense against advanced cyber attacks. By leveraging behavioral threat analytics tools on privilege accounts, security teams no longer receive just another alert. Instead, they receive meaningful alerts that can be instantly prioritized to give organizations the opportunity to disrupt an attack before it s too late. 1 Mandiant, a FireEye Company. M-Trends 2014: Beyond the Breach. April Page 1 CyberArk Software Ltd. cyberark.com 12

13 CyberArk s Privileged Account Security Solution The ten pains illustrated in this whitepaper are consistently creating security, compliance and productivity challenges for large IT environments. CyberArk solutions can help organizations address these pains while strengthening privileged account security and streamlining operational effort. About CyberArk CyberArk (NASDAQ: CYBR) is the only security company focused on eliminating the most advanced cyber threats; those that use insider privileges to attack the heart of the enterprise. Dedicated to stopping attacks before they stop business, CyberArk proactively secures against cyber threats before attacks can escalate and do irreparable damage. The company is trusted by the world s leading companies including more than 35 percent of the Fortune 100 and 17 of the world s top 20 banks to protect their highest value information assets, infrastructure and applications. A global company, CyberArk is headquartered in Petach Tikvah, Israel, with U.S. headquarters located in Newton, MA. The company also has offices throughout EMEA and Asia-Pacific. To learn more about CyberArk, visit All rights reserved. This document contains information and ideas, which are proprietary to Cyber-Ark Software Ltd. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, without the prior written permission of Cyber-Ark Software Ltd. Copyright by CyberArk Software Ltd. All rights reserved. 13