products:

Sorry,

there are no posts to show...


Helpful Resources

News:

A privileged account is one used by administrators to log in to servers, networks, firewalls, databases, applications, cloud services and other systems used by your organization.

These accounts give enhanced permissions that allow the privileged user to access sensitive data or modify key system functions, among other things. You can imagine, then, why they’re such an attractive target to hackers.

By gaining access to a privileged account, a hacker can wreak havoc on your business. For example, they can steal customer data, bring down your website, or shut you out of critical systems. And because the hacker is using legitimate credentials, it’s often difficult to pinpoint where an attack is coming from — if you detect it at all.

3 Reasons to Consider a Privileged Access Risk Assessment

To improve security posture and meet regulatory compliance, consider these three reasons why your business should conduct a detailed privileged access risk assessment:

Reason #1 – A Glaring Security Loophole

With the potential for exposure so high, you’d assume that businesses would be way ahead of this threat. However, many organizations are failing to devote the proper attention to closing the glaring security loophole that is privileged account management.

In many cases, weak passwords are used to protect these highly sensitive accounts. In fact, some use the default password — literally ‘password’ in some cases — and some use none at all. Others use stronger passwords, but share the same account between multiple users, increasing the account’s risk profile.

Even when privileged accounts are assigned to single users and adequately protected, they’re often not revoked when a user no longer needs them. Depending on the size of the organization, it’s estimated that there are up to four times as many privileged accounts as regular user accounts, many of them no longer in use. With every single account presenting hackers with an avenue of attack, this means that organizations are exposing themselves to a staggering amount of unnecessary risk.

Reason #2 – The Consequences of Exposure

A data breach costs the average organization as much as $150m in losses. At least one-third of customers take their business elsewhere when a breach is made public, even if they’re not personally affected. Then there is the cost of legal penalties that can result from failure to comply with security measures around the protection of sensitive data.

Many businesses can’t survive these legal and financial blows and quickly find themselves in the ground, but securing privileged accounts is not as simple as merely changing your passwords.

Reason #3 – The Problem with Privileged Account Security

The first step to securing privileged accounts is to perform a detailed audit. However, with so many of these accounts scattered across networks, servers and other key infrastructure, it can be almost impossible to get a true picture of how many there are, how (and if) they’re being used, and how secure they are.

Traditionally, a privileged account audit was a manual job requiring hundreds and hundreds of hours of IT man-hours, which of course carried a significant financial cost, too. The process was long and complex, and many organizations avoided it because they simply found it too daunting, expensive, or both. Today, that doesn’t have to be the case.

That’s Where CyberSheath Comes In

CyberSheath’s expert team uses advanced technology to perform privileged access risk assessments in a fraction of the time, helping you to:

  • Identify all privileged accounts on-site, in the cloud, and in your dev-ops environments.
  • Locate all privileged credentials, such as passwords, access keys, and SSH keys.
  • Discover weaknesses and highlight accounts that are vulnerable to credential theft.

With our technology and expertise, there’s no reason to shy away from a privileged account security audit — and no excuse to put your business at risk. Contact us today to find out how we can help keep your privileged accounts and your business safe and secure.

In today’s world strong, unique passwords are a necessity. Whether it is a domain administrator password for an organization or a personal online banking account, it is crucial to safeguard information by having a robust password making access to any account or system less easy.

The Old Standard for a Secure Password is No Longer Sufficient

In a recent interview, Bill Burr shared that he regrets some of the recommendations he made back in 2003 regarding what makes a good password. In retrospect, he surmised, humans generally have difficulty generating strong passwords.

As a refresher, Mr. Burr wrote NIST Special Publication 800-62, Appendix A in 2003. This document essentially defined a strong password as a mix of upper and lowercase letters, numbers, and special characters. These days, a password needs other attributes to be considered strong.

What Not To Do

It’s is rather mind-boggling that some folks use the most simplistic passwords for business and personal use. Even in this era of security breaches and data loss, common – and incredibly weak – passwords include “password”, “12345678”, and “qwerty” (http://www.computerworld.com/article/3024404/security/worst-most-common-passwords-for-the-last-5-years.html)

Why does this happen? According to the 2017 version of the NIST Special Publication 800-62, “Research has shown … that users respond in very predictable ways to the requirements imposed by [password] composition rules” (NIST, 2017).

Bottom line: People can and should do better at creating and managing passwords.

What To Do

Two solutions can help you and your organization support better password creation and management. They are:

  • Two-Factor Authentication (2FA) – 2FA it is based on using something a user has and something a user knows to authenticate him or her. A perfect example of 2FA is an ATM. To get money out, a user must insert his ATM card (something he has) and enter a PIN (something he knows). While 2FA used to only be applicable to organizations, many online services such as Gmail, Facebook, and Amazon now allow a user to enable 2FA to further secure access to his or her personal accounts. The website https://www.turnon2fa.com/ provides easy-to-follow tutorials on how to enable 2FA on these services.
  • Password Manager – A password manager such as the opensource Keepass (http://keepass.info/) or the enterprise-level CyberArk privileged account management (PAM) solution provides a cryptographically secure repository and the ability to generate passwords that are both random, complex, and long. (Having your web browser remember your password is not a password manager). A password manager delivers a mechanism to securely store and generate strong passwords so that a user does not have to remember them. In the case of CyberArk, there are also many other features, such as automatic password rotation, privilege session monitoring, and integration with applications for App to App account management.

CyberSheath specializes in the deployment and customization of CyberArk’s PAM solution to fit each customer’s specific use case – and we can help you build the solution that meets your organization’s unique needs. Contact us today for your free assessment.

What do you and your security team need to successfully improve privileged access controls? The first blog in this series offered direction on making the core decisions that power your overall strategy. Next we recommended ways to engage stakeholders across your organization. Now it’s time to provide guidance on the team, techniques, and tools you’ll need to drive this initiative.

Here’s What You Need to Get It Done

  1. Realistic expectations

Make sure you go into your privilege account management (PAM) deployment with a clear view of the process and its impacts on your organization. It is common to scope the initial “quick win” phases to be completed in a matter of weeks, in order to gain traction and prove the value of the initiative. From there, the initiative is often launched with a phased approach. Rolling-out better-privileged access controls across an enterprise can typically be a year to multi-year effort. Your organization can expect to see results in terms of risk reduction almost immediately after deploying improved controls around the first set of accounts.

During implementation, there will be some temporary disruption to business processes. Post-deployment, business processes are often sped up. If well-planned, improving privileged access controls can provide benefits such as increased efficiency, fewer user errors, increased uptime, and easier troubleshooting. After the initial deployment, an ongoing effort will be required to ensure that privileged access controls keep up with changes in the environment.

  1. The right people with the right skillsets

PAM deployments can be fairly complex to deploy and maintain. Solutions typically touch multiple IT domains (Windows, Unix, databases, network devices, etc.) and require a broad set of skills from basic troubleshooting to creating custom scripts and code. This typically requires at least two dedicated engineering resources, a project manager, a service owner, and some engagement from professional services.

Required skillsets include:

  • Technical/design – Members of the security team must be skilled in handling technical issues, and questions and any arguments that might arise. Areas of expertise should include:
    • The infrastructure used in the organization
    • Platforms such as Microsoft Windows and Linux
    • Applications and databases
    • Application development practices with respect to permissions
    • Privileged account security controls
    • Security control design
    • Processes around technology service management
  • Security governance and risk – The team should be able to help business and IT leaders make governance and risk decisions and guide the optimization of policies and processes. This requires a thorough understanding of business operations and goals. Knowledge of identity and access management (IAM) and account provisioning and maintenance practices are also important aspects.
  • Project management – A large-scale privileged access security initiative requires methodical planning and has many moving parts. You will need people with strong project management skills on the team to keep all of the various stakeholder groups aligned and focused on what needs to be done and to make sure it happens.
  • Soft skills – The security team will need people with diplomatic skills and an aptitude for negotiation, politics, and communication. Members of the team need to be able to explain why new processes need to be followed and be competent at listening to stakeholders and taking their concerns into consideration.
  1. Measurable and meaningful metrics

Your PAM deployment needs to deliver results and measurable outcomes. Metrics are valuable to illustrate the need for better controls, measure improvements, and demonstrate the value of the program.
Use metrics to:

  • Test effectiveness of controls – Through penetration tests, measure the potential vulnerabilities of credentials and show how vulnerabilities have been reduced after implementing improvements. Test how long it would take for an attacker to get control of domain admin accounts.
  • Show when to make course corrections – Measure access violations before and after implementing control changes. Be prepared to rework controls if expected results are not materializing.
  • Gauge the effect of controls on efficiency – Calculate the amount of time admins are spending on tedious tasks, such as resetting passwords.
  • Measure how the controls impact system availability – Applications with embedded credentials must periodically go through scheduled downtime so credentials can be changed. Take note of the amount of downtime required. Admin errors can inadvertently bring down a system. Compare the time required to recover from an outage before and after implementing control changes.
  • Assess impact on application performance – Test application performance and functionality before and after removing embedded passwords from applications.
  1. A plan with milestones

After identifying priorities, you’ll need to further break down the identified priority areas into phases. Here is one approach to how to phase your PAM deployment.

  • Phase 0: Installation and basic configuration of the PAM solution
  • Phase 1: Built-in accounts – Identify and onboard built-in accounts and enable password rotation on the accounts.
  • Phase 2: Domain admins and individual account privilege revocation – Address the onboarding of domain admin accounts into CyberArk. Isolate and monitor sessions of Tier 0 assets. Remove or minimize any local server privileged accounts or users that have been added to the “Administrators” group on local servers, with the exception of any that are required for service accounts. Create a process to do this as an ongoing process.
  • Phase 3: Databases, exchange admins and Tier 1 session isolation – Isolate and monitor Tier 1 assets. Onboard any privileged database and exchange admin accounts you may have.
  • Phase 4: Network devices, business apps, security systems, legacy systems – Identify any onboard network devices, business apps, and various security appliances. Use Privilege Session Management and the PAM’s MFA capability to protect privileged account access to legacy systems.
  • Phase 5: Service accounts – Identify and begin addressing the management of service and App IDs.
  • Phase 6: Desktop least privileged model and whitelisting of apps (OPM/EPM) – Allow only certain users to elevate their permissions. Limit which apps and commands can be run by which users.
  • Phase 7: Corporate accounts – Protect corporate communication and external financial systems accounts and other accounts. Use privilege session management to allow users to use these accounts without revealing the password.

Keep your momentum. Implementing more advanced controls across a large enterprise often requires a certain persistence and fortitude. A common reporting model is a weekly status meeting for the project team and a monthly review by an executive steering committee.

  1. The Right Tools

Start by understanding your strategic goals and formulating your approach, then find tools that will help achieve those goals. Take the time to select privileged account security and management tools that support your specific security and enterprise requirements. Adopt processes to get the most out of tools and to help you stay on track. Some technology features that are especially important include the ability to:

  • Securely store credentials in an encrypted vault
  • Create a single sign-on environment
  • Uniquely identify users and restrict their use of privileged accounts
  • Limit the length of privileged sessions for a user or application
  • Centrally monitor and record the use of privileged accounts
  • Automate password changes to run on schedule or trigger when an employee leaves the organization
  • Scale and meet performance demands in a large enterprise environment
  • Integrate with the organization’s infrastructure, applications, and other security technologies

Other key tools and technologies that can be helpful include:

  • Enhanced monitoring and alerting systems such as Security Information and Event Management systems (SIEM) and Security Analytics/Big Data Platforms
  • Technology for two-factor authentication to be used for remote access, third parties, and infrastructure administrators who have root or domain admin privileges

The theft of privileged credentials and privilege escalation are key stages in most successful cyber attacks. Today’s threat environment is prompting many enterprises to address the gaps in their security program to better protect privileged credentials. It requires a strong combination of technical and soft skills, a methodical project plan, appropriate tools, and persistence.

CyberSheath has helped implement comprehensive enterprise-wide initiatives in privileged account security. We work with over 50 organizations ranging from the largest financial, healthcare, and development firms with thousands of users to new implementations at organizations with only a handful of IT users. Contact us to get your PAM initiative started.

You’ve made the three decisions necessary to start building your privileged account management (PAM) plan. The next step is to build consensus and create stakeholder buy-in by having four pivotal conversations with key members of your executive, business process, and IT teams.

Who You Should Talk to – And What You Should Say

Executive Team – Lead with, “It’s time to make privileged account management a priority.”

Getting Ready & Intel

  • Secure buy-in from the top – The initial deployment will require senior leadership to understand the risks of unsecured privileged accounts, and just as importantly they will need to specify deadlines by which all privileged accounts need to be compliant. The prioritization of a successful PAM project will be driven from the top down. In addition to establishing accord with the CIO/CTO/CISO, It’s important that you have engagement with the compliance and financial executives.
  • Garner support to obtain budget and resources – Executive leadership can rally employees to make your PAM initiative an organizational priority, impart a sense of urgency and ownership across the organization, and prevent it from being derailed by minor issues.

Talking Points

  • Analysis of high-profile breaches – Describe how privileged access controls factored into particular breaches and relate it to your company’s own risk profile.
  • Penetration testing results – Assess how long it would take for a skilled adversary to compromise your organization’s privileged accounts. Show what assets an attacker can get to.
  • Benchmarking – Reference industry practices for securing privileged access.
  • Compliance requirements – Outline the privileged access regulations applicable to your organization.
  • Proof-of-concept results – Do a proof-of-concept in which you implement increased privileged account monitoring and report on the results.

Business and IT Process Owners – Lead with, “Let’s optimize how privileged credentials are used.”
Getting Ready & Intel

  • Emphasize teamwork and desire to increase task efficiency with initiative – Privileged accounts will be involved at some level in almost every critical business and IT process. For the most part, improving the security around privileged accounts will not deeply affect existing processes. Work closely with the owners of these processes to understand the underlying credential usage, and bring that knowledge into the design of controls and see opportunities to improve security, streamline tasks, and reduce errors.
  • Make business users allies – By helping leaders in business and IT to improve the security and efficiency of their processes, your security team can gain important allies. If prominent leaders in business and IT are champions of the initiative to improve privileged access controls, it can influence the privileged users within their groups.

Talking Points

  • Who needs elevated privileges and when – Review how privileges are used as an opportunity to reinforce the principle of least privilege.
  • Feasibility of restricting an account’s use of certain commands – Talk about automated privileged access technology and how granular restrictions can be enforced.
  • Risks and process change necessities – Balance the level of protection with the need to meet other business goals such as efficiency.
  • Principle of separation of duties for this process – Look for ways to redesign processes so that technology automatically enforces separation of duties.
  • Preventable error patterns – Talk about configuring controls to ensure certain steps require approval.
  • Applications in use – Uninstall applications with embedded credentials if the application is no longer used.
  • Session script requirements – Consider redesigning a script so that it requires shorter privileged sessions.

IT Admins and Other Privileged Users – Lead with, “We’re going to change privileged access procedures for the better.”

Getting Ready & Intel

  • Show empathy and challenge perceptions – Buy-in from IT Admins is essential for the success of your PAM initiative. The “default” view of IT administrators is that they could do their job better with unfettered access and freedom to choose their own tools. They may see any additional steps or restrictions as making their job harder and slowing them down.
  • Select security team spokesperson wisely – The team member that you put in charge of this type of conversation needs to articulate the threat and technical knowledge of the platforms and applications involved. If your security team doesn’t deal with objections at a detailed technical level, it’s possible that the process will be derailed.
  • Know that other privileged users are typically more accepting – Staff in non-IT roles who have privileged access – such as those who need to work with financial reports and bank accounts – tend to be more accepting of new controls.

Talking Points

  • Changes to workflow – Demonstrate that the PAM effort will streamline some tasks and make how they operate with credentials much more efficient .
  • Strong executive mandate – Discuss the importance of the initiative and persuade administrators to accept changes.

Developers – Lead with, “How can we better secure the use of privileged credentials in these apps?”

Getting Ready & Intel

  • Acknowledge that refactoring applications can be a challenge – Many applications, scripts, and configuration files include hardcoded privileged credentials. There are inherent difficulties in updating older code and platforms make it hard to operate with less than the highest possible permissions.

Talking Points

  • The right level of privilege for each application – Work together to determine the privilege rights for all your organization’s applications.
  • Understanding least and excessive privileges – Discuss the principle of least privilege. Help developers understand the consequences of excessive privileges.

Handling objections
Be prepared to manage objections that may emerge during deployment.

  • “You can’t take away those rights – I need them!” – Often you will need to convince people that the privileges they are losing are not necessary. Point out that the change protects them by reducing the risk that their accounts will be compromised.
  • “I tried it and it doesn’t work.” – As changes to controls are implemented, users may report problems. Proactively set up a process ahead of time for responding to concerns. Be responsive as people adopt new processes and technologies. Maximize usability of the control design.
  • “I don’t have time for this.” – When you encounter pushback, strong executive sponsorship of the initiative is extremely important. Focus on the value you bring to users and help them to see the benefits.
  • “This feels like Big Brother.”  – Administrators can be sensitive about increased monitoring. Reassure them and address governance issues such as what reports are run when and by whom.

Technical expertise and soft skills are needed to pull off these conversations. The third and final blog will expand on the skillsets you need to be successful and will explore some of the elements of an effective PAM deployment.

And if you’d like assistance from our team on how to have these conversations with your stakeholders, contact us. We’ll here to help.

With cyberattack headlines in the news each week, it’s more important than ever to do everything possible to safeguard your systems and data. One way to accomplish this to prevent the theft of highly privileged credentials. Better managing access to privileged accounts can help prevent cyber adversaries and rogue insiders from going after privileged credentials as a way to gain broad and undetected access to your information systems.

How do you improve your privileged account management?

This blog is the first in a series of three articles where we walk you through decisions you need to make to power your strategy, conversations you should have to create stakeholder buy-in, and resources you require to launch your privileged access initiative. Let’s start by discussing the core decisions your organization needs to make at the outset of the process.

  1. What should you do and when? You need to prioritize what accounts require better protection and be aware of when to make changes. A focus on privileged accounts must be done within the context of your overall security strategy and weighed against other goals. Be aware that if privileged credentials are not properly secured, other controls meant to protect the infrastructure could be rendered ineffective.
    • Conduct an initial “baseline” discovery of privileged accounts. Before beginning privileged account management (PAM) deployment, perform an initial discovery of the privileged accounts in your environment. Using a tool such as “DNA” from CyberArk can give you valuable insight into the types of accounts that exist at your organization. Having a good baseline report will help you create a phased approach to securing the privileged accounts.
    • Evaluate risks and prioritize implementation. Determining order of priority requires identifying which accounts represent the biggest risks. Focus on accounts that provide elevated access to the organization’s most critical systems and build your PAM plans from there. Engage the compliance department early, to understand the requirements behind reporting and various security controls.
    • Plan the timing and rollout of your PAM project. Once you’ve conducted a discovery, you may be in for a surprise as to just how many privileged accounts you have. Given the scope and reach of the project, it will make sense to adopt a phased approach. Deploy at least a limited proof-of-concept demo to help you identify any immediate limitation in the vendor’s platform that may require custom development for your organization. We’ll be discussing how to plan your rollout in further detail in the third blog in this series – so stay tuned for that valuable information.
  1. What’s the best mix of controls? There are many options for how to proceed. The right approach for your organization requires intelligently deploying the most effective controls for each privileged account access use case.
    • Take a layered approach. Reducing the risks around privileged accounts requires a layering of preventive and detective controls. Preventive controls can help stop the unauthorized activity. Detective controls can help to discover it when it occurs, either maliciously or by mistake before any significant damage occurs and/or provide an audit trail and accountability.
    • Use detective controls to avoid over-limiting access. The use of detective controls can often help in achieving the balance between enabling and restricting access. Rather than putting in place preventive controls that may be overly restrictive, in some cases, a better approach would be less restrictive access that is carefully monitored for any violations. Detective controls are especially important in cases where increasing restrictions is simply not feasible.
    • Secure credentials used by applications and scripts. Credentials used by applications and scripts often need better security controls. If possible, applications should meet the following requirements:
      • The credentials for the account should be stored securely.
      • The account password or SSH key should be changed regularly.
      • The application should be designed using the principle of least privilege.
    • Use compensating controls for embedded credentials. For applications that cannot be refactored right away, compensating controls might be appropriate such as:
      • Configure the account to be non-interactive and unusable for logging on.
      • Increase monitoring on the accounts.
      • Use analytics to detect possible misuse of an application’s account.
  1. How much is enough? Controls should provide better security without encumbering business processes.
    • Make sure you select a PAM solution that will scale with our business. Pick a vendor that can scale with your organization. A PAM solution may become the cornerstone of your company’s security posture, eventually requiring all IT personnel to engage with it. A great PAM solution will have SDK (Software Development Kits) and APIs (Application Program Interfaces) so that you can extend your investment into the platform to meet the complex requirements of tomorrow.
    • Seek a win-win situation. Security and usability need not always be in conflict. Unlike many other types of security controls, better processes and technologies for privileged access management can offer the business improved productivity and user satisfaction.

In our next blog, we’ll cover the four pivotal conversations you need to have with your stakeholders to help your project succeed.

If you’d like assistance launching a PAM project to help secure your enterprise, contact us. We’ve got the experience and expertise to help build you a solution to meet your privileged account access needs. Contact CyberSheath today! 

 

On Friday of last week, Europol reported that a worldwide attack using a piece of ransomware known as “WannaCry” hit more than 150 countries and infected at least 200,000 victims. Europol Director Rob Rainwright said that “the global reach [of the attack] is unprecedented. The attack appears to be targeting businesses and large corporations in the healthcare, financial and infrastructure sectors; these sectors have highly sensitive information ripe for a hostage.

Ransomware is malicious software, a virus, that has two purposes. The first is to encrypt the contents of a machines hard drive, preventing the user from accessing the information without entering a unique key or password. The second purpose is to act as a worm and spread to as many machines as possible. With a large footprint of infected machines, the attacker can then hold the data for ransom, promising to provide the password or key to decrypt the data once the ransom is paid in bitcoin (untraceable digital currency).

The WannaCry ransomware appears to exploit a vulnerability in the Microsoft XP operating system that was discovered as a result of the recent NSA tool dump. It’s unclear at this time whether the ransomware was developed by the NSA or just as the result of the NSA’s day one exploit stockpiling. Microsoft president and chief legal officer Brad Smith responded to the attack stating that it “provides yet another example of why the stockpiling of vulnerabilities by governments is such a problem”. Smith continued his comment stating that “this most recent attack represents a completely unintended but disconcerting link between the two most serious forms of cybersecurity threats in the world today — nation-state action and organized criminal action.

While IT and Security teams have no doubt been working around the clock over the weekend to prevent the spread and manage the fallout, some key actions organizations should take in the immediate fallout are as follows:

  • Immediately backup important and sensitive data in case you are infected soon.
  • Update to the latest Microsoft security patches.
  • Update all anti-virus and conducting immediate scans.
  • Scan all inbound and outbound emails for malicious attachments.
  • Send out a companywide awareness email warning employees about the attack and to be cautious of scams and malicious emails.

Moving forward, organizations should consider a more proactive approach to dealing with ransomware as opposed to reactive. In August of last year, CyberSheath Security Engineers wrote about the rise of ransomware and how using sandboxing techniques in daily operations can be 100% effective against malware attacks when used in combination with least-privilege. Adding to defense in depth, implementing a privileged account management solution can be used to prevent ransomware from spreading to critical servers by securing privileged accounts, and in combination with isolating critical servers with a secure jump host such as CyberArk’s PSM, can be a highly effective combination in combating malicious threats.

Let the security professionals at CyberSheath help you become proactive, not reactive. You can learn more about our approach by viewing our Privileged Access Management service area or clicking the button below to download our detailed Privileged Access Management datasheet.

In the previous privileged account blog, we described the three main categories of privileged accounts: Local Accounts, Directory Accounts, and Application Accounts, as well as some of the best practices for maintaining those accounts.

In this week’s blog we will discuss the pros and cons of various privileged account access models.

For the purpose of our discussion, suppose we have a targetwindows-based server called “PrintServer01.” This server is a member of the domain and its primary function is that of a print server. Mostly the domain administrators need privileged access to this server, in order to provision new network printers or troubleshoot existing printers’ queues and drivers. There are various options for giving the domain administrators access to the server, which we will discuss from the least secure model to the most secure model.

1: Sharing the local “Administrator” password (without a PAM Solution).

Perhaps the least security-conscious model is sharing the local “Administrator” password between the various users that need to administer the machine (without a PAM Solution). As the old Benjamin Franklin quote goes “Three may keep a secret, if two of them are dead”. This solution happens often because it’s the easiest to deploy (you simply tell whoever needs access the password). Often systems, such as legacy network appliances, only have the option to have one administrative account, which forces organizations to adopt this type of solution.

Pros:

  • This model is easy to implement for any system.

Cons:

  • There is almost always no attribution to the actual person that is logged in as this user.
  • It can be hard to communicate the new password between multiple team members, so passwords are either not changed or changed but not following security guidelines (for example adding a simple number on the end or setting the same password on multiple systems).
  • It’s tough to keep track of password versions, especially if the last person to change it leaves the company or is not available. This can make certain administrator’s a huge liability to an organization, especially when they have the “keys” to vital servers.
  • Access logs are kept on the local system.

2: Creating individual local accounts or adding named domain users to the “Administrators” group on the target server.

The next solution that many organizations adopt is to add “named” users to the “Administrators” group on the server. If the server is on the domain, organizations “add” domain users to the “Administrators” group, otherwise they create a local user first, and then add it to the “Administrators” group. This model is certainly better than the first model we discussed, however it adds a number of security maintenance complications:

Pros:

  • There is attribution to the named users that have access. If a production server unexpectedly restarted during business hours, a log would indicate who initiated the restart.

Cons:

  • It can be time-consuming to set up individual users and add them to each server.
  • It can be even tougher to remove users who no longer need access from each server.
  • Passwords for the users that were created “locally” are often forgotten, and there is a need to reset them often, creating un-needed operational resource drain.
  • Users will set the same password, on their account, across multiple servers, exposing the servers to the “pass-the-hash” attack.
  • There is limited visibility as to “who” has access “where” without running specialized tools to discover access on all servers.

3: Adding domain groups to the “Administrators” group on target servers and using secondary domain accounts:

As an improvement to creating “local” users and explicitly adding domain users to the Administrator’s group, organizations typically create domain groups, such as “PrinterAdmins” and then make a member of the local Administrators group on the “PrintServer01” server. Subsequently, the domain users that require access to this server would be added to the “PrinterAdmins” group, and would thus be able to log into the “PrintServer01” server, with Administrative privileges to make the appropriate changes.

Security conscious organizations only add “secondary” domain accounts to these privileged groups, to minimize the risk of a compromised “daily” account being used as an attack vector.

Pros:

  • There is attribution to the named users that have access.
  • It’s fairly easy to maintain the groups once they’re created (for example to remove access from users that no longer require it).
  • There is more visibility to who has access to the various servers, from a central (domain) view
  • The domain groups can be audited.
  • It’s relatively straightforward to identity ownership of particular servers based on group membership (to contact owners in case of a problem).

Cons:

  • Access logs are kept on each server, and can potentially be wiped clean.
  • It can be time-consuming to create domain groups.

4: Shared local “Administrator” access with a PAM Solution.

In this solution which we consider being one of the best security practices, an organization has deployed a central Privileged Access Management solution, such as the CyberArk Privileged Account Security Solution. This is used to manage the local privileged accounts on each server. Account access to each server is controlled with an access-control model, such as the CyberArk “Safes”, that dictate who can see the password for the account. Users that are able to see the password can “check-out” the password to a particular system as needed. The passwords can be rotated automatically after each use and changed often, and there are options for workflows (owners of the account can grant temporary account access to users that require it). There might be additional PAM capabilities, such as the CyberArk PTA (Privileged Threat Analytics) installed, that would alert the security management of unusual user activity.

Pros:

  • Access can be easily provisioned through the PAM solution.
  • There is no need to create multiple users.
  • Each target server has a unique username/password combination, preventing the pass-the-hash attack.
  • There is a central place to conduct a system-access audit.
  • A good PAM solution can be used to record user activity and trigger system alerts when suspicious behavior is detected.
  • Added benefit of built-in workflows for account access.
  • User access can be revoked from a central location.
  • Password versions are kept in a central location (for example: if there is a need to check the password for a restored Cisco device from 6 months ago).
  • Access logs are kept in a central location, and cannot be easily deleted.
  • Access history can be kept for years, long after the servers are decommissioned.

Cons:

  • Can require additional local accounts, if more than one user needs to access a specific machine at a time.
  • Users get only one “desktop” on a server, which can be seen by other users.
  • Additional cost for a dedicated PAM solution.
  • Potentially additional complexity for end-users of the system.

As the organization’s security posture grows, it should constantly evaluate its Identity Management policies and procedures. CyberSheath highly recommends implementing a central PAM system as a toolset and framework for managing privileged accounts. 

This month CyberSheath co-sponsored a table with CyberArk at the annual California Tech Summit, at the convention center in Anaheim. We had a lot of great discussions with conference participants and conference presenters. Often times at events, like the Tech Summit, as a vendor you are asked many questions throughout the day regarding the service or product you are representing. One frequently asked question that came up was “what exactly is a privileged account?”  In order to address that question, we should first discuss the various types of user and service accounts that exist in a typical enterprise.

There are three main types of accounts that exist: local accounts, directory accounts, and application accounts. We will take a look at them to discuss under which circumstances those accounts are typically considered “privileged,” although keep in mind that some organizations can have broader definitions of what it means for an account to be privileged.

The 3 Main Types of Privileged Accounts

1: Local Accounts

Local accounts are defined on specific systems, and can only be used to log into that system such as the Administrator account on a desktop PC.  With local accounts, we can have identically named accounts on different systems, and they typically have their own individually managed password. For the most part, accounts that are members of the “Administrator’s” group on Windows-based systems are considered privileged.  In Unix/Linux, accounts that have root-level access are considered privileged. On network appliances, devices that have write-capabilities are typically considered privileged. It’s possible to use local accounts for file access, so any account that has access to highly-sensitive data should also be considered privileged. A privileged access management tool can be used to keep track of who has access to those accounts and to rotate the passwords automatically. A good tool can reduce the risk of local accounts by setting each one of them up to have a different password.

2: Directory Accounts

Directory accounts, also known as Domain accounts are defined in a central location. For example, we can have a user called John.Smith defined within the Microsoft Active Directory. The accounts defined in directories have to have unique names and passwords.  In order to login or use a particular system, the directory account has to be either defined individually or be a part of a group, that’s authorized on the system. The built-in Active Directory accounts, such as Administrator, should be considered privileged, as well as any accounts that are added to the Domain Admins group. Where it gets a little trickier is with standard “named” user accounts. Standard “named” accounts are typically used by end-users to log into their desktop PC’s and conduct routine functions such as checking their email and are not considered “privileged,” unless they’re added to the local “Administrator’s” group on a server or a desktop.

It can be difficult to detect and keep track of when a particular “named” user account is added to the “Administrator’s” group to one of the hundreds/thousands of computers in an enterprise, and tools like CyberArk’s DNA need to be utilized to discover these instances. Many enterprises create a secondary “named” account for users that need to have administrative access, for example, “John_Smith!,” where the exclamation point indicates that the account is privileged.  After CyberArk’s DNA discovery process is complete, the privileged accounts should be defined, monitored, and controlled through a central PAM suite.

In some cases, directory accounts can be created to run a certain service or application, for example, a “bind” directory account for an application that needs to look up and/or change properties in the domain. The directory service accounts should be considered privileged, especially because their passwords are static, and often they are a member of the local “Administrator’s” group on the server where they operate. A privileged access management tool, such as CyberArk, can be used to rotate passwords, and “push” the application password to the service that needs to run it.

3: Application Accounts

Application accounts tend to be local and directory accounts, and are typically used for authorization into a specific application. For example, a Microsoft SQL database might have a user called SA. Sometimes application’s utilize local or domain accounts in order to run, the key differentiator from other accounts types is that the applications do not require an interactive login in order to work. The passwords for application accounts are often stored within the application, or in an external configuration file. Where an application account is considered privileged is highly dependent on the permissions and file-access that the account will have within the application.  A mature PAM solution can help rotate the passwords of the Application accounts, and even provide the password directly to the application from the central vault, preventing the need to store it in a clear-text configuration file.

In next week’s blog, we will discuss a “shared” privileged account access model that is possible with a central PAM solution. In that model, enterprises control account access through a PAM solution, and instead of adding “named” domain accounts to servers, users are given access to the “shared” privileged accounts.  Learn about our approach to within our Privileged Access Management service area.

On June 18, 2015, NIST released the final version of SP 800-171, which provides guidance for protecting the confidentiality of Controlled Unclassified Information (CUI) residing in nonfederal information systems. In August 2015, DFARS clause 252.204-7012 replaced the original NIST 800-53 r4 controls with NIST 800-171, which we detailed earlier here.  CyberSheath has integrated the requirements laid out in NIST 800-171 into our security assessment process that included all NIST 800-53 controls and in-depth reporting on the DFARS-specific controls.
Out of the new 800-171 controls, a handful deal specifically with privileged access.  Privileged Account Management (PAM) is a way for organizations to manage credentials with administrative rights to ensure the accounts stay safe.  CyberArk, a PAM solution and trusted CyberSheath partner, offer a suite of products designed to optimize privilege account creation while keeping the keys to the kingdom safe.  The following is a list of top 7 ways in which CyberArk’s PAM solution can help an organization meet the SP 800-171 guidelines:

7 Ways a PAM Solution Can Help You Achieve DFARS Compliance

NIST 800-171 Requirements for Access Control

Number one

NIST 800-171 3.1.1 Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).

At its core, CyberArk is a system that was designed from the ground up to be a comprehensive PAM solution. The most basic functionality of CyberArk is the ability to create generic privileged accounts on target systems, provision those accounts within CyberArk, and subsequently allow specific users or groups to access those accounts.

Number two

NIST 800-171 3.1.2 Limit information system access to the types of transactions and functions that authorized users are permitted to execute AND 3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions.

In addition to identifying, securing, and monitoring privileged accounts, CyberArk has a component called “On-Demand Privileges Manager” or OPM for short.  Using the OPM component, organizations can limit the commands that individuals are able to execute on Unix/Linux systems and even Windows. For example, the OPM solution replaces the Unix sudo command with a PIMSU command which requires the user to authenticate against their credentials in the Vault, checks if they’re allowed to execute the command, and can allow instant execute permissions while at the same time starting a recording and alerting a security officer about the transaction.

Number three

NIST 800-171 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

The basic CyberArk architecture helps to address this control because access to various system accounts can be segregated by safes, and only certain users or groups would have additional access to those safes. In addition, CyberArk comes with an out-of-the-box account access workflow capability called “Dual Control.” Using Dual Control policies, even an individual has full permissions to access an account; they would need a confirmation from a colleague with similar access before they can use an account. The ability for everyone in the group to see that that the request and approval workflow, diminishes the opportunity for malevolent collusion between rogue individuals.

Number four

NIST 800-171 3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.
With CyberArk it is possible to enforce the least-privileged access model using the safe permissions. In addition there is quite a bit of transparency and ease of running audits, to confirm that this control hasn’t become lax. It’s possible for managers to be able to see which users have accessed an account, without granting the managers the permissions to use the actual account.

Number five

NIST 800-171 3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions.

Using CyberArk, it may be easier to separate the “daily” accounts from “secondary accounts.” In fact, the need to create a second account for privileged access can be eliminated using the idea of a “shared” account. The idea of having “shared” accounts was frowned upon in previous access models, however, when accessing those accounts through CyberArk it is possible to have full attribution because shared accounts are mapped to CyberArk user accounts. A user could safely use a non-privileged account to access their email, and use the same account to access CyberArk, where they would be able to check-out privileged accounts. Note, in this model, it is highly recommended to have two-factor authorization of the user’s daily account into CyberArk.

NIST 800-171 Requirements for Identification and Authentication

Number six

NIST 800-171 3.5.3 Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

Out of the box, CyberArk supports RADIUS, RSA Token, SAML, and PKI authentication. These multi-factor authorizations can help an organization not just with the CyberArk accounts, but in effect all of the organization’s privileged accounts. For example, if all of the organization’s privileged accounts are protected by CyberArk, a user would be required to use multi-factor authentication to log into CyberArk, thereby expanding the multi-factor protection to the privileged accounts.

Number seven

NIST 800-171 3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and nonprivileged accounts.

CyberArk’s ability to automatically change passwords, based on policy, on individual accounts helps to prevent this “pass-the-hash” attack. Each account, on each server, can have its own unique password which is regularly changed. This acts as a “replay-resistant” authentication method by keeping a potential attacker from moving through the organization by hopping to different servers using compromised credentials.

With these seven tips, you can effectively manage your privileged access within your organization while gaining DFARS compliance.  With a vast majority of APT using privileged accounts to traverse your network, it is imperative that you protect your privileged accounts. CyberSheath’s engineers are well versed in fine-tuning the configuration of the Privileged Account Management suite; providing an automated, monitored, and controlled elevated privileged access.  You can learn more about our approach by viewing our Privileged Access Management service area.

Modern Healthcare recently reported that “Health insurer Centene Corp. is hunting for six computer hard drives containing the personally identifiable health records of about 950,000 individuals…” While this potential data loss doesn’t come close to the monumental data breaches suffered by Anthem, Blue Cross and Blue Shield and others in 2015; it highlights 5 actions that companies of any size in the healthcare space should be taking now to optimize security.

5 Actions You Should Take to Improve Security

1: Manage and Encrypt Assets

Know what you own, who it’s assigned to and if it’s mobile encrypt it. Wrap these efforts into your existing Governance, Risk, and Compliance efforts for HIPAA Hitech, PCI DSS and any other relevant business requirements around compliance. As a goal measure once, comply many but whatever you do encrypt and track your endpoints.

2: Manage Your Vulnerabilities

Establish a capability to assess the risk of systems, applications, and IT services by evaluating the prevalence of vulnerabilities in your environment. You won’t ever be able to remediate them all but you don’t have to. Focus on the high risk/high probability first and establish a documented, repeatable program to continually address this basic requirement for IT security.

3: Privileged Access Management

Monitor and manage your privileged accounts as these will be the accounts likely exploited in a successful breach. Ignoring this accepted minimum standard of care for information security is akin to not encrypting laptops, it’s a necessity, not a luxury.  For further explanation, we discuss privileged account exploitation more in-depth in our white paper, CyberSheath APT Privileged Exploitation.

4: Protect the Network

Provide protection for your network environment with a set of network security tools to detect, alert, and automatically respond to malicious activities targeting your environment. Prioritize requirements here to fit your budget and make tradeoffs were required to include protection for internally and externally available systems, email platforms, and internet use via browser.

5: Incident Response, Logging, and Monitoring

Build a capability to monitor critical systems, applications, and IT services as well as to detect and respond to incidents and/or breaches when information is improperly handled, accessed, or transmitted as it inevitably will be at some point. Do what you can with what you have as not everyone can afford 24/7 monitoring. Outsource where necessary but do not get caught with no plan or capability or you will spend exponentially more being reactive.

How Can CyberSheath Help Your Organization?

All of these efforts can and should be integrated with the day-to-day delivery of IT operations to maximize your efficiency and effectiveness. CyberSheath will work with your organization, large or small, to help secure your valuable assets. CyberSheath offers security assessments to help your organization begin with a clear understanding of where you stand in regards to industry standards and regulations.

There are many reasons to implement a Privileged Account/Identity Management (PAM) system, including audit and IT security standards compliance, risk mitigation, automation of password management, transparency of user activity, etc. Today we’d like to focus on some of the specific reasons why it is important to implement, maintain, and enforce the utilization of a PAM system for a company that is planning for, or foresees a significant Reduction in Force (RIF).

As pundits are predicting a bear market in 2016, IT managers are starting to prepare their contingency plans for dealing with potentially hundreds or thousands of employees, whose employment will need to be terminated abruptly. A PAM solution can help mitigate some of the very real risks associated with terminating an employee, particularly one that has key access to IT systems. Employees may react differently in the face of termination. The most technical employee assets may instantly become the biggest liability. The terminating employee may have full administrative access to hundreds of critical servers and network appliances that comprise the environment, creating tremendous potential risk to the company.

The following 5 reasons demonstrate how a PAM system can prevent disaster resulting from a RIF

1: Instantly Prevent Access

A well-implemented PAM solution will offer the capability to lock out specific employees from access to all servers at the press of a button.

2: Changing All Privileged Passwords Within Minutes

The PAM solution can not only prevent the terminating employee from seeing what the current Administrative Passwords are, it can also be used to initiate a password change on all of the systems that the employee previously had access to.

3: Recording Activities

A PAM solution can record the activities (on video in the case of Windows, or text in case of Unix/Linux). This capability can be invaluable in cases where terminating employees are given a deferred RIF notification (for example a two-week notification). The recording can discourage the employees from stealing company data as they’re leaving, installing dangerous Trojans or rootkits, as well as provide a trail of employee activity.

4: Documenting System Passwords

Often RIFs can be a chaotic undertaking, and without a PAM solution, it can be nearly impossible to guarantee that all critical knowledge, particularly system passwords, have been transferred or documented for the company. It could be difficult to contact a terminated employee, sometimes months after termination, to see if they remember or will release a password for even non-critical systems such as a Twitter account. There have been a couple of notable cases where rogue employees have held company passwords “hostage,” including the infamous case of Terry Childs and the city of San Francisco’s Department of Telecommunications and Information Services (DTIS).

5: Documenting Systems and Access

In addition to a Configuration Management Database (CMDB), a PAM solution can help the company identify systems that a particular employee supports. If the system has been around for a significant amount of time, a report could be run to see which systems the employee has ever interacted with, using privileged accounts.

How Can CyberSheath Help Your Organization?

In summary, it’s critical to implement and enforce a Privileged Access Management solution, long before the employees are notified of a RIF. CyberSheath’s engineers are well versed in fine-tuning the configuration of the Privileged Account Management suite; providing an automated, monitored, and controlled elevated privileged access.  You can learn more about our approach by viewing our Privileged Access Management service area.

Despite the advances in security surrounding user accounts, there is still one type of account that has proven to be an anomaly in the cybersecurity world – privileged accounts. Standard user accounts at one time represented a significant issue for businesses but over the years security technologies and business processes have evolved to become very good at automating the control and access of standard user accounts. From onboarding and termination processes, inactivity lockouts, authoritative source correlations, and role-based access permission models, businesses today are efficiently managing the end-to-end life cycle of standard user accounts.

This is a very common and natural progression and evolution for an area that is weak in cybersecurity. On the other hand, when we look at privileged accounts, which represent the most important and powerful users, we see an anomaly in the natural evolution of cybersecurity and a massive disconnect from the businesses reality to cybersecurity.

Bloomberg Businessweek recently reported that the global cost of cybercrime is more than $400 billion. In our joint-research report with CyberArk, a company dedicated to protecting high-value assets, we found that accounts with elevated privlieges were involved in 100% of cybersecurity attack breaches. This has been a reoccurring theme with similar findings in the Verzion’s 2014 Data Breach Investigations Report. Privileged accounts are significantly undervalued in their criticality and risk to the business. This has driven the advancement of a set of security tools that specialize in privileged accounts with varied acronyms, such as Privileged User Management (PUM), Privileged Identity Management (PIM), and Privileged Account Management (PAM), to name a few. In short, these tools apply a strictly enforced set of processes around the management of privileged account but implementing these tools can be difficult as IT teams have a tendency to exhibit prejudice towards anything that may add an extra step to their daily operations.

Udi Mokady, CEO of CyberArk, stated that for many larger organizations there are three to four times as many privileged accounts as there are standard user accounts. Coupled with an overabundance of data showing that attackers target privileged accounts and regulatory compliance mandates (e.g. PCI) stringent security controls for these accounts, the question must be asked- why aren’t businesses doing more to protect them?

 

As one CIO from a Global Products and Services Company astutely put it,
“I can measure the importance of privilege accounts in gigabytes exfiltrated.”

Unfortunately the solution isn’t as black and white as it may seem. Specifically, there are two types of privileged accounts that businesses find predominantly difficult to secure: service accounts and local administrator accounts. Both are hard to find due to the disparate variables used to reliably identify them. Moreover, local administrators can sometimes be necessary for teams to execute their responsibilities and likewise, service accounts are often essential to system and application integration by facilitating communication and action within a complex distributed computing environment.

What is the way forward? The standard Identity Management (IdM) solution isn’t enough. Extend your IdM solution with a Privileged identity Management (PIM) application that brings forward identity controls to privileged accounts across your environment. Select a PIM application that meets demands of your business. SOX, PCI, HIPAA, to NERC-CIP all contain mandates that require stringent security controls over data, access to that data, and user accounts.

Let the identity management experts at CyberSheath help you manage all accounts with access to critical data and infrastructure. CyberSheath has partnered with CyberArk to deliver CyberArk’s best-of-breed Privileged Account Security suite with a ground-breaking toolset. In addition to knowledge of industry best practices, CyberSheath engineers can use CyberArk’s DNA tool to discover exposed accounts and oversaturation of administrative and Root account access that inevitably exists in organizations. CyberSheath engineers are experienced in reading DNA mappings and applying the findings to real-world solutions.

The Keynote sessions here at RSA 2013 kicked off yesterday and Art Coviello, RSA Executive Chairman, focused on the importance of big data and the opportunities that it presents security teams from an intelligence perspective. He’s right, the opportunities are tremendous and customers are anxious to better leverage “big data” but documented and repeatable process along with baseline implementation of critical controls are prerequisites for taking advantage of “big data”.

The actionable intelligence that can be gained from big data is only useful if it causes an organization to take the RIGHT actions in the correct sequence with measurable outcomes. Conceptually leveraging big data makes perfect sense but the implementation will yield more of the same firefighting that bogs down security organizations today if it’s not part of a documented strategy with measurable outcomes enabled by rigorous process and a thorough understanding of the controls you currently have in place.

The actionable intelligence that big data can provide could very well enable an organization to quickly and efficiently mitigate an attack by correlating unstructured data in a context that directs an SoC analyst to take appropriate action. Attack mitigated, the good guys win right? Maybe not…are we really still just addressing the symptoms and not the root cause? The attack is a result of a vulnerability that was exploited and resources are being expended on the incident response because resources were not expended on preventative maintenance. Perhaps if the control to prevent the attack in the first place had been documented, implemented and measured the attack would never have happened.

I realize that implementing critical controls won’t stop every attack but there is such a great opportunity to do some fundamental and meaningful work around implementing critical controls to stop attacks that get overlooked.

It’s just good hygiene. Would rather brush your teeth, floss and get regular dental examinations or be really good at getting fillings?

FAQs:

Cybersheath Blog

3 Reasons Why You Need a Privileged Access Risk Assessment

A privileged account is one used by administrators to log in to servers, networks, firewalls, databases, applications, cloud services and other systems used by your organization. These accounts give enhanced permissions that allow the privileged user to access sensitive data or modify key system functions, among other things. You can…

Incident Response – Learning the Lesson of Lessons Learned

“Those who do not learn from history are condemned to repeat it.” Over the years, variations of this famous quote have been spoken by everyone from philosophers to world leaders. The message — that we must learn from our mistakes or continue to repeat them — is also highly relevant…

What is DFARS 252.204-7012 and NIST SP 800-171?

With the Department of Defense (DoD) promising the release of an update to NIST Special Publication 800-171, it is imperative defense contractors understand what DFARS 252.204-7012 and NIST SP 800-171 Clause is and how noncompliance with the Clause will impact their business.  Compliance is mandatory for contractors doing business with…

Our Trusted Partners

Cyberark McAfee Thycotic RSA Tenable Alien Vault Alert Logic Trace Security