products:

Sorry,

there are no posts to show...


Helpful Resources

News:

As cyber-attacks become more frequent and sophisticated, addressing tighter security needs has become a priority for the federal government. Enforcement of “Controlled Unclassified Information” (CUI) protection continues to intensify as private contractors and organizations are now required to upgrade their cybersecurity systems and overall procedures to keep up with these increasing threats. On April 24, 2018, the Department of Defense (DoD) issued draft guidance for assessing contractors’ System Security Plans (SSPs) and the implementation of security controls in NIST Special Publication (SP) 800-171.  If you’re a defense contractor, you’re required to comply with these regulations and provide “adequate security” for networks where covered defense information (CDI) is processed, stored, or transmitted. DoD issued two draft guidance documents. The first, “Assessing the State of a Contractor’s Information System,” provides guidance on four different objectives.  They include what must be in an RFP, how the source selection authority would evaluate the requirement, what resources are available for that evaluation, and the contract provisions that will be needed to implement the requirement during performance. The second draft guidance document, “DoD Guidance for Reviewing System Security Plans and the NIST SP 800-171 Security Requirements Not Yet Implemented,” was developed by DoD to determine the risks that an unimplemented security control has on an information system, and which of the unmet controls need to be prioritized. What does “adequate security” mean? At a minimum, defense contractors must implement the requirements in NIST SP 800-171 to become compliant. Contractors need to provide an SSP to prove the implementation of the security requirements, and also develop plans of action and milestones (POA&M) that describe how any unimplemented security requirements will be met.

Unimplemented Controls Receive a Value Rating

NIST 800-171 is comprised of 110 technical controls to ensure the best security policies and procedures.  DoD has decided to assess the risk of unimplemented controls by assigning a “DoD Value” for each security requirement ranging from 5 (highest impact on the cybersecurity system) to 1 (lowest impact on the cybersecurity system). These priority codes are used for priority rankings that NIST assigns to the NIST SP 800-53 Revision 4 security controls that are used for government information systems and which form the basis for NIST SP 800-171.

Non-Compliance is Not an Option 

In 2018, proposed DOD guidance is already moving to full enforcement of compliance. Compliance failures can lead to more serious consequences than a data breach.  Failure to comply with DFARS can lead contractors to incur penalties either by the United States Government (civil, criminal, contractual actions in law and administrative), or by individuals and private organizations that were damaged by lack of compliance (actions for damages).

  • Bid Protests: While SSPs and POA&Ms are important for determining “adequate security,” it’s still unclear the exact part they’ll play in bid protests and the implementation of NIST SP 800-171. After reviewing the implementation status during the pre-award stage, the DoD can make an unacceptable or acceptable determination, and ultimately decide if the contract should be rewarded. Another option is to evaluate implementation as a “separate technical evaluation factor.” During the pre-award process, contractors may choose to protest terms where a solicitation’s treatment of NIST SP 800-171 implementation fails to be consistent with DoD’s guidance. On the other hand, if a contract was rewarded to another contractor, disappointed offerors may consider challenging the award to another offeror where the assessment of the protester’s or awardee’s implementation of NIST SP 800-171 is inconsistent with the guidance documents. If the DoD notices inconsistencies between the implementation of NIST SP 800-171 and your SSP and POA&M, they could award the contract to another contractor. During 2018, contract protests awarded to higher-priced bidders were based in part on compliance with cybersecurity and employing more than the minimum security requirements in NIST SP-800-171.
  • Termination Risk: The accuracy of your SSP and POA&M, along with providing proof that you’re moving toward full compliance, is crucial. For the most accurate evaluation, the draft guidance states that solicitations and contracts must include contract data requirements (CDRLs) to “require delivery of System Security Plan and any Plans of action after contract award.” Now that both SSPs and POA&Ms are a contractual obligation, failure to be in compliance may provide a basis for termination if compliance isn’t completed. Or, if the SSP does not accurately state the implementation status of the contractor’s cybersecurity.
  • DCMA Audits: DoD has recently stated that as part of its audit function, DCMA will pull out all the stops to confirm all contractors have an SSP and POA&M.  However, DCMA will not be providing an analysis if the SSP fully complies with the NIST 800-171 security requirements. It’s unknown at this point if the DCMA would leverage any of DoD’s guidance in its review.
  • False Claims Act: If a contractor is audited by DoD and found not to have implemented DFARS/NIST 800-171, the contractor can be on the receiving end of numerous penalties. For example, if your SSP misrepresents your actual cybersecurity status, DoD can bring an action based on fraud, which is a False Claims Act violation. DoD may also be able to prove that the original SSP was key to the Department’s award decision. If DoD’s argument is successful, your earnings under the original contract are at risk, along with the reputation of your organization.

Make Compliance a Priority Before it’s Too Late!

At CyberSheath, we know that implementing these new security controls can seem like a daunting undertaking. We’ve successfully assessed and implemented the required NIST 800-171 controls for leading organizations in the defense industrial base supply chain.

CyberArk is considered a global leader and pioneer in providing privileged access security, and for good reason.

Because CyberArk provides the most advanced Privileged Account Management (PAM) solutions in one incredible platform CyberSheath made the strategic decision to build out our PAM professional services with a CyberArk focus.   One of the challenges for our mid-sized managed services customers was fitting CyberArk capabilities into resource-constrained budgets. CyberArk, trusted by the world’s leading businesses, and more than 50% of Fortune 100 companies, was often inaccessible to mid-sized businesses. We are happy to report, that has changed and CyberSheath now offers CyberArk as a flexible, multi-tenant, pay-as-you-go-managed service offering!

CyberArk’s Advanced Security Solutions are Accessible and Affordable to Mid-Sized Businesses

CyberArk recently unveiled an expanded offering for Managed Security Service Providers (MSSPs) like CyberSheath, featuring groundbreaking multi-tenant, pay-as-you-go-option. The new groundbreaking multi-tenant offering allows CyberSheath to extend the reach of the CyberArk Privileged Account Security Solution to companies of all sizes. CyberSheath can now enable you to meet your compliance and operational PAM objectives for DFARs 252.204-7012, NIST 800-171, Sarbanes Oxley (SOX), Payment Card Industry Data Security Standard, General Data Protection Regulation (GDPR) and more.

The multi-tenant version of the Privileged Account Security Solution offers consumption-based pricing to meet the unique needs of mid-sized businesses.

CyberArk’s flexible pay-as-you-go method enables CyberSheath to offer CyberArk’s advanced solutions without the huge up-front costs. CyberSheath delivers privileged access security as a single or multi-tenant solution, and your business only pays for what is deployed.

CyberArk’s pay-as-you-go model opens up privileged access to those businesses that previously lacked the funds or bandwidth for a large upfront investment. Mid-sized businesses will no longer be left out in the cold from obtaining CyberSheath’s award-winning PAM professional services, previously only affordable to larger organizations. CyberSheath can now help your business reduce privileged-related security risk from malicious insiders and external attackers leveraging the best PAM solution on the market.

CyberSheath offers a wide range of managed security services to a diverse range of customers, improving overall security and IT operations across multiple platforms. With CyberArk PAM now a part of that offering for mid-sized businesses we can easily accelerate onboarding, and control and monitor their privileged accounts 24/7.

CyberArk’s MSSP offering enables customers to scale their privileged-access security offering over time, and, most importantly, improve overall security. CyberSheath’s privileged-access security professional and managed services, leveraging a best in class capability, reduce risk across all environments — on-premises, in hybrid-cloud environments and at the endpoint.

CyberSheath is the Most Trusted CyberArk Professional Services Provider

We’re the most trusted experts in privileged account security. That’s why more organizations choose CyberSheath for the highest quality implementation of all CyberArk professional service and managed services. We’ve been delivering CyberArk managed services for some of the largest customers in the defense, financial and utility sectors for years and now we are thrilled to offer these services to mid-market customers.

Let CyberSheath protect and monitor your privileged accounts, enable compliance with all regulatory requirements and measurably improve your operational security.

Your organization is always looking for ways to increase security, ensure reliability, and reduce costs. One way to accomplish this is to leverage the power, flexibility, and cost-effectiveness of cloud solutions. With CyberArk now officially supporting the cloud deployment of their privileged access solution, it’s time for you to reap the benefits of deploying your privileged account management (PAM) solution in the cloud.

CyberSheath can help. Over the past several months, our engineers have been working with organizations like yours to assist them in gaining all the benefits of migrating and deploying their CyberArk solutions in the cloud.

Here are Compelling Reasons to Run CyberArk in the Cloud

Shifting to cloud deployment makes sense for a few important reasons. Also, it’s important to note that currently, CyberArk’s PAM solution is supported on Microsoft Azure and Amazon Web Services.

Cloud deployment of your CyberArk solution can result in:

  • Lower cost – See below cost example of running CyberArk on Azure or AWS for a year. Cloud deployment also helps you reduce the number of infrastructure support teams and resources needed, further benefitting your bottom-line.

  • Improved reliability – AWS and Azure both carry up-time guarantees, which takes the onus off of your infrastructure. The simplified cloud-based solution means less down-time caused by having the application dependent on multiple teams and other layers of the architecture. AWS, in particular, offers many powerful yet simple options to make the application fault-tolerant and rapidly recoverable.
  • Increased flexibility – By deploying CyberArk in the cloud, you can painlessly and quickly enhance architecture designs as needed. You can rapidly deploy an entire application environment for a proof of concept within hours and then throw it away when finished. Also, hybrid architectures are possible, making stepping into the cloud easy and painless. For example, sometimes it makes sense to keep the Vault server hosted on-site and deploy all or additional component servers into the cloud.

Think Moving to the Cloud is Right for You?

Consider the following:

  • Investing in your cloud administrator resources will make sure you get the most benefit out of deploying CyberArk in the cloud.
  • Moving the keys to your organization into the cloud means you need to properly secure access to cloud service management tools. Be sure to design access and roles to be aligned with the cloud service provider’s best security practices.
  • Best security practices for the network architecture in the cloud can enhance your existing security design, but only if integrated properly. Security concerns and solutions vary between cloud service providers. Be sure your deployment follows both the cloud vendor and Cyberark’s best practices.

CyberSheath engineers certified in both CyberArk and cloud services can manage the entire solution for your organization. Contact us – and to see how we can help move your CyberArk solution to the cloud.

 

You’ve done some of the hard work already. Your organization is onboard with ramping up cybersecurity efforts – and you’ve even acquired CyberArk to help support your Privileged Account Management (PAM) efforts.

Now it’s time to implement your PAM solution.

As you know, a PAM system helps prevent the theft of highly privileged credentials – and 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.

But implementing a PAM solution can seem like a daunting task – and you don’t want a breach at your organization to be your incentive to move forward. How do you get started and make sure your PAM solution doesn’t become shelfware?

Gain traction of your PAM project with a phased approach.

At CyberSheath, we have seen many organizations in various levels of PAM maturity. In our experience, a phased approach is the best way to deploy a PAM solution. This method enables you to tackle finite pieces of the project quickly – and helps you make a positive impact on your organization’s security in as few as 30-days. We recommend running each phase as a sprint (usually targeted to take 30 days). Keep in mind that sometimes a phase will need to be divided into mini-sprints.

Here are the top-level phases to help you craft your PAM approach. While you may shift the order of phases to fit your organizational priorities and infrastructure complexity, we have found this hierarchy of action to be effective at rapidly identifying and remediating key security gaps.

PhaseArea of focusWhat it isWhy it is a priorityWhat you need to do
1Built-in Local AccountsFor Windows, a built-in account is a type of user account that is created during installation.These accounts have passwords that are known to multiple people – some of whom have probably left your organization. Often the same password is used across multiple systems enabling lateral Pass-the-Hash attacks to gain access to much of your infrastructure. These accounts are homogeneous and tend to be the easiest to onboard as a first step in your PAM initiative.
  • Identify and onboard buy-in accounts for Windows (Administrator) on servers and desktops, Unix (root).
  • Enable password rotation on all accounts.
2Domain AdminA built-in group on Microsoft Active Directory, the Domain Admin is typically assigned to administer all domain servers. Members of this group have full administrative rights to many components of the corporate infrastructure.These few accounts are a master key, having access to everything. Securing this small group is a fast way to help safeguard your systems.
  • Onboard Domain Admin accounts into CyberArk.
  • Switch to the ‘shared privileged account model’ and revoke individual domain-admin permissions.
3Database, Exchange, and Application AdminsDatabase, Exchange, and application administrators manage and maintain database management systems and application software.This is where the data is. These accounts control access to all the intellectual property at your company.
  • Isolate and monitor Tier 1 assets.
  • Onboard any privileged database and Exchange admin accounts.
4Network DevicesNetwork devices are components used to connect computers or other electronic devices together so that they can share files or resources.Access to your network can be an entry point to any other systems at your organization.
  • Identify any onboard network devices, business apps, and security appliances.
5Service AccountsA service account is a user account created explicitly to provide a security context for services running on various a operating systems and applications.Often these accounts have high-level access – and passwords compromised on one of these accounts provides a foothold for access across your network. Passwords on these accounts often have not been changed in years – so security is suspect.
  • Identify and begin addressing the management of service and App IDs.
  • Purchase additional licensing as required.
6Corporate AccountsExternal accounts are created in your company’s name and provide third-party services not available internally. Examples include Twitter, Facebook, and credit and bank accounts.Unauthorized access to these accounts can adversely impact your brand and your bottomline.
  • Protect corporate communications and external financial systems accounts.
7Desktop ComputersThese are assets given to employees to support their work and productivity including desktop and laptop computers.Individual desktops can provide an entrance point for hackers to infiltrate corporate systems as passwords tend to never change and often passwords are the same across all devices.
  • Enable only specific users to elevate their permissions.
  • Limit which apps and commands can be run by which users.

Here’s a useful graphic to help with planning the phased approach for your PAM solution. Download it for your reference.

 

Stay tuned for more information coming soon on how to prepare for and scope an individual sprint to tackle one or more of these areas.

If you would like experienced help identifying or implementing PAM phases for your organization, you can rely on CyberSheath’s skilled SMEs. Contact us to learn more and to get started.

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! 

 

Major data breaches and an always evolving cybersecurity threat and fraud landscape mean that the financial sector is under constant pressure to keep customer and corporate data safe from hackers.

Last year saw the biggest data breach in UK history with over 20,000 Tesco Bank customers losing money from their accounts. Also in 2016, hackers used hijacked privileged credentials to steal $81 million from vulnerable customer accounts at The Bangladesh Central Bank.

It’s a tough cybersecurity landscape out there – and financial institutions need to stay ahead of hackers. Cybersecurity leaders recently gathered at the SWIFT Business Forum in London to discuss the challenges faced by banks including:

  • Changes in targets and tactics – JF Legault, cybersecurity global head at JP Morgan, spoke about the changing nature of cybersecurity threats stating, “We saw the advent of malware targeting wholesale banking platforms. Criminals stopped going after simple, low-value monetary amounts and shifted to high-value payment platforms. The reason they did that was a lot more yield on the crime(s) they committed. We also saw a shift toward business email compromise… [and] a high number of breaches affecting the financial sector that led to fraudulent messages.”
  • False positives – Banks are wasting valuable time flagging activities in the anti-money laundering monitoring systems that are not actually fraudulent. These “false positives” take time away from strategic activities. Anthony Fenwick, global head of treasury and trade solutions and AML compliance at Citi Group, pointed out, “Our biggest problem in this industry is false positives…the use of electronics and AI have to go hand-in-hand with the best humans. The idea that we remove all human activity from this process misses the point of what we are trying to do.”
  • Insider threats – Regional vice-president for UK, Ireland, and Northern Europe at CyberArk, Matt Middleton-Leal, underlined that banks most fear attacks that hide behind insider privileges. “They allow cybercriminals to appear as legitimate users, giving them unprecedented freedom to work their way up to their most valuable financial assets.” Gottfried Leibbrandt, CEO at the financial messaging vendor SWIFT chimed in that, bank customers “will always be the weakest link, but at the same time the response should not be ‘let’s fix the weakest link’ but you have to take an end-to-end view.”
  • Consumer-friendly usability – According to Royce Curtin, managing director of global intelligence at Barclays, big breach is a huge concern, but that must be balanced with providing customers with solutions that want to use. “We work very hard and take very seriously the responsibility of building systems and trust for services that people feel comfortable using.”

How Banks Can Overcome These Issues

  • Improved communication – Better communication and intelligence sharing at financial institutions is a good first step toward building a more robust cybersecurity program.
  • Multiple-layered security – Concentrating on multiple-layered security also helps safeguard valuable bank information.
  • Actionable insights – Many banks are looking for intelligence that can be quickly turned into an effective response, especially when it comes to landscapes where breaches are more likely to occur. Create actionable intelligence inside the banks and publish it out. Take a strategic view and identify suspicious behaviors (i.e. here is a set of accounts and a volume of transactions that we should be mindful of) so that proper security alerts and timely, effective responses can be undertaken.

How CyberSheath Can Help

CyberSheath can help companies in the financial sector address many of these issues with security consulting services and expert guidance. We provide Privilege Account Management, which provides strong protection inside the perimeter, security assessments, and best practices recommendations based on experience solving security-related problems for major financial clients. Contact us for your FREE security assessment.

Chances are if you are involved in maintaining your organization’s cybersecurity, you’ve had more than a few sleepless nights after hearing the disastrous consequences of another entity’s breach. This story is no different.

DNS Hijack and Extremely Well-executed Spoofed Sites Fool Bank Customers

Earlier this month, the security firm Kaspersky detailed the wholesale takeover of a yet unnamed bank in Brazil. The attack itself was a quintessential DNS hijack where the attackers took over several of the bank’s domains. For a period of five hours, customers were directed by NIC.br (the company that manages the bank’s DNS service and, incidentally, the domain registrar for the Brazilian top-level domain, .br) to spoofed versions of the bank’s legitimate sites. The spoofed sites were reportedly near perfect down to having their own valid SSL issued in the name of the bank.

Hackers Obtained SSL Certificate for Rogue Sites

After they could exercise control over the domain, the attackers applied for an SSL certificate from the non-profit certificate authority Let’s Encrypt. In an interview with Wired.com, Josh Aas, founder of Let’s Encrypt, states that entities are issued certificates when they can properly demonstrate control of a domain – which in this case the attackers were able to do.

Per the Let’s Encrypt website (letsencrypt.org), the company only offers domain validation (DV) certificates which are sufficient for HTTPS. Kaspersky’s ThreatPost write-up of this incident revealed that the certificates were issued the day before the spoofed sites went live, suggesting that the attackers could exercise a level of control over the bank’s domains in the days leading up to the attack.

Countless Bank Customers Duped into Providing Account Details

These days, consumers are much savvier regarding how, when, and where they share their confidential information. With the HTTPS designation and the seemingly identical spoofed sites, a large number of bank customers were tricked into providing their account details on the spoofed sites.

How to Make it More Difficult for Attackers to Infiltrate Your Organization

There are several lessons to learn from this hack. First of all, it is important for organizations to work to stay ahead of hacker tactics. Perhaps if the bank in Brazil had followed the tips listed below, the bank and its customers would have been protected from a breach.

  1. Include external accounts in your privilege access management strategy. When identifying privileged accounts in your organization include internal accounts as well as external accounts that could pose a risk to your organization. Locking down internal root and administrator accounts is not sufficient. Privilege access management must include all accounts that provide elevated access or could impact your organization’s system or reputation, including those for your social media presence; or in the bank’s case, the organization’s DNS service provider. If the affected bank had included their NIC.br account in their privileged access management solution, they may have been able to prevent this attack.
  2. Rotate passwords frequently both in your organization and with your personal accounts. Also, two-factor authentication should be used when possible. Had this bank rotated the password more frequently, there is the possibility they may have been able to protect themselves from this attack. If the password for their account at NIC.br changed frequently, the attackers would have needed to compromise it each time.
  3. Get organization validation (OV) or extended validation (EV) certificates when appropriate for your organization. Certificates are not created equally. In this case Let’s Encrypt offers Domain Validation (DV) certificates, not OV or EV certificates. To the general public the nuanced difference between these is likely lost especially when their browser simply displays a site as “secure”, but the reality is theses certificates have significant differences. OV and EV certificates offering more validation and provide more trust.

Don’t let a hack happen to you. Contact Cybersheath to learn more about our recommendations for safeguarding your organization. Contact us today for a FREE consultation and we’ll make sure you have a strong cybersecurity defense strategy!

Source: https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/

Source: https://threatpost.com/lessons-from-top-to-bottom-compromise-of-brazilian-bank/124770/

 

 

As part of an ongoing series on using privileged account management solutions to meet DFARS requirements, CyberSheath’s security consultants have explored technical controls in great detail, providing readers with real-world applications that make a meaningful impact. This week CyberSheath continues to explore NIST control 800-171, “separate the duties of individuals to reduce the risk of malevolent activity without collusion”.

Privileged account management solutions are valuable tools to meet the following NIST 800-171 controls:

  1. 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).
  2. NIST 800-171 3.1.2 Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
  3. NIST 800-171 3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions.
  4. NIST 800-171 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
  5. NIST 800-171 3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.
  6. NIST 800-171 3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions.
  7. 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.
  8. NIST 800-171 3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and nonprivileged accounts.

The fourth control, 3.1.4, is to “separate the duties of individuals to reduce the risk of malevolent activity without collusion”. In layman’s terms, organizations must segregate the duties and tasks that employees complete in order to minimize the chance that they could purposely plan and execute malicious activities.

Real-world examples of this scenario include ensuring an application development team does not have access to production code or compartmentalizing the information individuals on a team have access to, ensuring no one individual has access to everything. Separation of duties would prevent individuals from maliciously impacting production code or limit the fallout of an insider threat.

A privileged account management solution like CyberArk allows organizations to provision access to applications, operating systems, databases and many other devices through the use of the Enterprise Password Vault. Organizations can create a purpose built shared accounts for applications, systems, databases, etc., and grant access to those specific accounts based on the separation of duties. That way, when contractor one needs to access information, they use the shared account they have been provisioned access to, and contractor two uses a different account.

10-24-1.png

Before a contractor can even check out a credential, organizations have the ability to implement account access workflows. This workflow can require contractors to fill out a form that specifies a reason for access, how many times they will be accessing it, and the time frame they will access it. When the form is submitted, an authorized individual like a manager can approve the request, giving the contractor access to the password. This feature is called Dual Control, and by using this feature, organizations can ensure that managers or authorized individuals can grant access for specific duties or functions. Dual Control can be configured so that authorized individuals are only able to approve, but not access the account, ensuring separation of duties between roles. Dual Control can also be configured so that teammates can approve other teammate’s access ensuring that at least two people are aware of account access. This entire request and approval process leaves a full tamper-proof audit trail.

To further ensure that malicious activity is not taking place, organizations can implement a policy of “one-time-use” passwords, where after a given time period (say 24 hours for example) the password will be changed automatically. In combination with the CyberArk Privileged Threat Analytics (PTA) tool, organizations can detect suspicious credential activity usage, trigger an alert and automatically respond to the unauthorized access in real-time. For example, if contractor #1 normally uses an account between a certain time period or location, using that credential outside of the normal baseline would trigger an alert and response.

10-24-3.png

CyberSheath’s implementation engineers and security consultants have real-world experience assisting organizations to fulfill their DFARS and privileged account management needs. Download our security assessment datasheet to learn more about how CyberSheath can help your organization get ahead with privileged account management. Subscribe to our email updates to stay up to date with our DFARS series and other security posts.

CyberSheath’s security consultants and implementation engineers have previously written about utilizing privileged account management solutions to meet DFARS requirements, and this week we continue to explore DFARS control requirements in detail.

The latest post in the “In-Depth Look at PAM Controls for DFARS Requirements” series, CyberSheath reviews a third NIST 800-171 control that when utilizing a PAM solution like CyberArk, makes for very effective control. These NIST 800-171 controls include:

  1. 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).
  2. NIST 800-171 3.1.2 Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
  3. NIST 800-171 3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions.
  4. NIST 800-171 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
  5. NIST 800-171 3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.
  6. NIST 800-171 3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions.
  7. 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.
  8. NIST 800-171 3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and nonprivileged accounts.

The third control, 3.1.7, is to “prevent non-privileged users from executing privileged functions and audit the execution of such functions”. In layman’s terms, do not give users who do not need privileged access the ability to execute privileged tasks, as well as the ability to audit privileged tasks.

In CyberSheath’s previous posts, we have discussed the concept of least privilege and using tools like CyberArk’s On-Demand Privileges Manager (OPM) and Viewfinity to technically enforce the least privilege while allowing elevated privileges when necessary. As a refresher, a “least privilege” access model means that end-users are given the bare-bone access required to do their everyday basic job functions. When users need to execute privileged tasks, they can either check-out an account from a Password Vault database, use the OPM or use Viewfinity on their workstation.

The CyberArk Privileged Account Management suite includes the Privileged Session Manager, a component used primarily as a jumpbox to transparently connect to target machines using secured privileged accounts. Since all of the traffic is redirected through the PSM jumpbox, it is also possible to record the sessions and monitor them live.  Auditors and Investigators can search for users that retrieved a password (whether the action was to view or copy the password or connect to a system using the target account).  The audit capabilities can be further bolstered by requiring users to provide reasons as to why they need access to the privileged account, and even requiring correlation to a Service Desk ticket number.  Recordings of the sessions can be searched for titles of specific applications that may have been launched (such as gpedit or regedit) for Windows-type recordings, or any text for UNIX type recordings.

10_12_1.png

CyberSheath’s implementation engineers and security consultants are well versed in the practical application of NIST 800-171 controls, DFARS, and privileged account management. Download our security assessment datasheet to learn more about how CyberSheath can help improve your organization’s security posture and implement effective security controls. Subscribe to our email updates to stay up to date with our DFARS series and other security posts.

Last week CyberSheath began a new series, “In-Depth Look at PAM Controls for DFARS Requirements”, dedicated to providing a detailed analysis on how privileged account management solutions play an important role for organizations in meeting DFARS requirements.

In the series’ first post we detailed control 3.1.1, one of the eight NIST 800-171 requirements that Privileged Account Management solutions offer well-fitting controls for; these NIST requirements include:

  1. 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).
  2. NIST 800-171 3.1.2 Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
  3. NIST 800-171 3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions.
  4. NIST 800-171 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
  5. NIST 800-171 3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.
  6. NIST 800-171 3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions.
  7. 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.
  8. NIST 800-171 3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and nonprivileged accounts.

The second of these eight NIST 800-171 controls, 3.1.2, is to “limit information system access to the types of transactions and functions that authorized users are permitted to execute”. In layman’s terms, only give access to those that have permission or approval for specific task or purpose. The reason for this control is to ensure that users only access information systems for the specific tasks and functions they are supposed to execute and prevent them from completing transactions or functions they shouldn’t be doing.

Most Privileged Account Management solutions will offer a form of account vaulting that allows organizations to partition account access based on the need-to-know and least privileged access model. For example, with CyberArk, companies can organize safes by the various functional and transactional requirements of the accounts stored in them. An organization could create a safe called “North-America-Unix-Local” which would be used to store accounts for the Unix team based out of North America, and the company’s administrators in Europe wouldn’t be granted access.

 

JC1.png

While the basic privileged account vaulting model could potentially meet the NIST 800-171 3.1.3 requirement, CyberArk provides two additional solutions to ensure that Federal contracting companies can meet and exceed the NIST 800-171 3.1.3 requirement; the On-Demand Privileges Manager (OPM) for UNIX and Viewfinity for Windows. Both of these products enforce a least-privilege access methodology at the operating system level and allow escalation of privileges for approved actions.

On-Demand Privileges Manager (OPM):

OPM allows organizations to define a policy (a set of rules) that dictate what commands users can or can’t run when connected to a UNIX server. When an end-user connects to a UNIX server with OPM installed, they execute a privilege elevation tool called PIMSU (Privileged Identity Management Switch User, similar to SUDO). The elevation tool will validate that the user logged in as has permissions to perform the elevated task and store a recording of all the elevated commands they execute during the session. This set of rules can be configured to allow or deny various commands that are defined as “privileged”.

JC2.png

For example, there are two contractors that both need access to a UNIX device that contains Covered Defense Information, and both need elevated privileges to complete unique tasks, two different policies can be created for each user that allow or prevent them from executing certain commands. This ensures that the information system access is limited to the transactions and functions a user is permitted to execute.

Viewfinity for Windows:

The Viewfinity application for Windows works in a similar way to OPM for UNIX. Viewfinity allows organizations to remove users’ local admin privileges on endpoints and servers. Like in OPM, organizations can granularly define trusted actions for applications, scripts, and commands which are managed on role-based access. This means that those same two contractors that need access to a Windows device containing Covered Defense Information can both elevate their privileges to run applications when necessary, but also ensure that they are allowed to execute those functions (or deny them).

JC3.png

CyberSheath’s implementation engineers and security consultants are leaders in both DFARS and privileged account management. Download our security assessment datasheet to learn more about how CyberSheath can help enable your organization to meet DFARS requirements. Subscribe to our email updates to stay up to date with our DFARS series.

In previous blogs, CyberSheath security analysts have identified new cybersecurity requirements from the recent changes to DFARS and have provided solution overviews for meeting those requirements and regulations. The series “In-Depth Look at PAM Controls for DFARS Requirements” will expand on previously mentioned regulations and provide a more granular look at how privileged account management solutions can play an important role in meeting DFARS requirements.

Back in March, we identified eight NIST 800-171 requirements where PAM suites can provide an ideal solution. These requirements include:

  1. 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).
  2. NIST 800-171 3.1.2 Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
  3. NIST 800-171 3.1.7 Prevent non-privileged users from executing privileged functions and audit the execution of such functions.
  4. NIST 800-171 3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
  5. NIST 800-171 3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.
  6. NIST 800-171 3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions.
  7. 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.
  8. NIST 800-171 3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and nonprivileged accounts.

The first of these eight NIST controls is to “limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems)”. In layman’s terms, only give access to those people, processes or devices that have permission or approval. As Yanni previously mentioned, this is the most basic functionality and purpose of a privileged account management solution. What may seem basic to some, it may be complex to others, so let’s break down what limiting access to authorized users looks like using the CyberArk Privileged Account Management solution.

In the context of DFARS, all accounts that provide access to “Covered Defense Information” should be considered privileged and be “vaulted” or stored within the hardened CyberArk database. These accounts are stored in various “safes” according to who should have access to them. For example, anyone with access to “Safe 1” in the image below, will have access to all the accounts within the safe. Safes 2, 3 and 4 would be provisioned separately.

09_12-1.png

With CyberArk, organizations can provision their employees access to these safes and accounts either directly using their preexisting account such as a personal Windows AD account, or provision an LDAP group of users instead, giving the entire group access. Organizations can implement their own internal approval system so that when a request is complete, it would automatically provide access to CyberArk and the credentials, and subsequently, the Covered Defense Information.

Additional controls can be implemented to lock down authorized access further, including ticketing system integration and time-restrictions. Ticketing system integration adds an additional layer of authorization by ensuring that those employees who have access to accounts can only use them when they have a valid ticket or reason (see example 1 below). Time-restrictions can limit the hours in which employees can access privileged accounts. If an employee attempts to access an account outside of the allowed time frame, they will be unable to access it, and a fully auditable event will be logged (see example 2 below).

09_12-2.png

Example 1: Ticket Integration

09_12-3.png

Example 2: Time-Restriction

 

There are advanced features in the CyberArk suite such as privileged session recording and transparent connections (using credentials without ever seeing them), and they all work on the basic foundation of limiting access to authorized users.

CyberSheath’s security consultants and implementation engineers are well versed in DFARS and privileged account management. Download our security assessment datasheet to learn more about how CyberSheath can help enable your organization to stay productive while meeting DFARS compliance. Subscribe to our email updates to stay up to date with our DFARS series.

Security researchers at Kaspersky Labs released their Threat Intelligence Report for the Telecommunications Industry Monday, revealing the top attack vectors against Internet Service Providers (ISPs) and Cellular Service Providers (CSPs). The report found that attackers commonly target employees with blackmail. Surprisingly enough, the report found that there are a number of employees that help voluntarily too. Threat actors have been identifying employees from a combination of publically available and data breach information, while dark web forums are full of employees offering their services in exchange for payment and often aide in the blackmailing process. Hacker-recruiters leverage the employee’s access to exfiltrate sensitive information.

Internet and Cellular Service Providers are not unique; all organizations are susceptible to this blackmail hacking strategy. Disgruntled employees are also commonplace. As the saying goes, “humans are the weakest link in security”, but that does not mean organizations cannot implement compensating controls to reduce the risk of an incident. One effective strategy to reduce the threat-surface of human interactions is to use the least privilege method for employee accounts, and use shared privileged accounts with a mature privileged account management solution.

Hackers blackmail employees for their access to infrastructure, applications, and data, and malicious insiders offer it up to the highest bidder. By stripping unnecessary access to these systems from employees’ personal accounts, companies minimize the risk associated with comprising these credentials; the principal of least privilege. However, there are many cases when employees have a legitimate business need to access at least some privileged accounts. Privileged Account Management solutions like CyberArk allow employees to use shared high-privileged accounts to access the necessary infrastructure, applications and data, all while keeping it secure, monitored and auditable.

Shared accounts alone are not enough; those same malicious insiders could simply provide the credentials of the shared account instead of their own. Some of the strategies that are possible with mature PAM solutions include one-time passwords, temporary access with account workflow, ticket-based approval, disabling account access during off-hours, and forcing access through a privileged session jumpbox. These strategies negate the risk involved from an insider threat by acting as compensating controls; they prevent disgruntled or blackmailed employees from simply sharing privileged credentials at a whim.

Malicious insider threats are on the rise, and with nearly 1 in 2 companies failing to properly enforce privileged credential controls, the chances are high that your company could be vulnerable. Let the privileged account experts at CyberSheath help your organization defend against the most uncertain, unknown and unpredictable, the human threat.

You can learn more about our approach by viewing our Privileged Access Management service.

Organizations continue to expand their application infrastructure at an alarming rate, whether it be in the cloud or on-site. Studies vary, but an estimated 48% to 65% of servers worldwide are run on some flavor of UNIX. The latest report from the Linux Foundation found that Linux is winning the battle in the cloud with an estimated 79% of cloud deployments running the operating system. Many of these UNIX devices are using SSH keys for authentication instead of passwords for the sake of convenience.

SSH keys are similar to privileged accounts, except they replace the need to use a traditional username and password. They allow the user, or an application, to authenticate with a username and key file instead. This removes the need to remember a password for each server, and instead just reference a file stored on your machine. SSH keys work in a public-private setup, where the public key is stored on the target device and the private key is what you use to connect to it with. These UNIX devices could include anything from your standard Red Hat Enterprise Linux server to many of the Internet of Things (IoT) devices.

Unfortunately, SSH key management is commonly overlooked and neglected. These SSH keys should be treated with the same security and care as privileged account credentials if your organization uses them. It’s common for users to simply store SSH keys on their local storage with no protection, making them vulnerable to theft. Many application and scripts are hardcoded to use SSH keys to communicate to.

In February of this year, cloud infrastructure hosting company Linode, LLC came dangerously close to causing a major breach for their clients. The company provided a common Ubuntu Linux cloud image to customers that utilized identical SSH keys, leaving the servers vulnerable to man-in-the-middle attacks. More recently on June 2nd, GitHub, an online project repository, revoked an “unknown number of cryptographic keys” when CloudFlare engineer Ben Cox discovered that a nearly decade-old vulnerability had left a “statistically significant” number of SSH keys vulnerable. Cox stated that the official repositories of Python, Spotify, and the UK Government we’re likely accessed using the compromised keys.

Organizations should implement a robust SSH key management program to reign in all the SSH keys and improve their security posture. While at first glance, this may appear to be a daunting task, mature Privileged Account Management solutions like CyberArk include tools that allow the identification, collection, organization, and storage of SSH keys in a simple, easy to use process. The CyberArk SSH Key Manager uses the Discovery and Audit (DNA) tool to detect and find all the SSH keys being used and creates a map reflecting the trusts formed by keys and target machines. The SSH Key Manager can determine which keys are being used, which are rouge, and which are expired to keep the environment clean.

Furthermore, the Privileged Account Management suite allows organizations to automatically rotate SSH keys, connect to target systems securely, monitor SSH key usage, and remove hardcoded keys. This allows companies to take advantage of all the same security features they use to manage their privileged accounts for their privileged SSH keys. With these tools, there is no excuse for why companies should not be taking the first steps to managing their SSH keys.

Let CyberSheath’s engineers help your organization establish an appropriate and effective SSH key management solution. You can learn more about our approach by viewing our Privileged Access Management service area.

A few short months ago in April, Verizon released their annual publication of the Data Breach Investigations Report, and after reviewing the report, we would recommend that you pack up the rod and reel, and throw your waders on because the theme of this year’s report is ‘gone phishing for credentials.’

Credential phishing dominated the top-five list of phishing targets this year at 91%. Secrets followed in a distant second with 6%, and bank, medical and personal targets with 1% each. “What do the attackers ultimately steal? A heck of a lot of credentials”, stated the report. This shows that “static credentials continue to be targeted by several of the top hacking action varieties and malware functionalities”. The investigation’s report also revealed that an astonishingly low 3% of targeted users actually alerted anyone that they had received a phishing email.

The Verizon report made the argument that it’s time to raise the bar for authentication and password management. Companies need to stop treating account and password management as a bush-league sport. Nearly 63% of confirmed security breaches were the result of “weak, default or stolen” credentials.

“We know that a standard username and password combo may very well be enough to protect your fantasy football league. We also know that the implementation of stronger authentication mechanisms is a bar raise, not a panacea. Even with all of that, 63% of confirmed data breaches involved leveraging weak/default/stolen passwords. This statistic drives our recommendation that this is a bar worth raising.”

– 2016 Verizon Data Breach Investigations Report

The 2016 report revealed that of the 905 phishing attacks reported, 89% were perpetrated by organized crime syndicates, and another 9% by state-affiliated actors. Out of all data breaches in the report, 89% were motivated by espionage or financial reasons. One of the most common patterns amongst hackers was targeting web applications in order to execute phishing schemes. Once hooked, the hackers would install malware on their machine, drop in a key logger, begin to export data and then proceed to use the stolen credentials to gain unauthorized access. This information shows us that companies are facing well-organized groups of hackers who are after political/military-related information and any other information that will lead to a profit. They know that targeting end-users will be their way in.

Based on the above-mentioned findings in the Verizon report, organizations can prevent breaches by tackling the issue on three fronts:

  1. Train their employees better to spot phishing attacks.
  2. Implement multi-factor authentication where feasible.
  3. Implement a privileged account management system for personal and shared accounts.

Humans are always, and arguably will always be, the weakest link in the security chain. By conducting routine phishing drills, organizations can test their employees’ ability to spot a phishing attack and report the incident to management. The drill can be as simple as mimicking a phishing email and sending it to all users, with the target URL being an internal website containing a warning that the user could’ve been compromised if this wasn’t a drill and relevant training information. It is better to find out where your weak links lie before an employee gets hooked on a real phishing scheme.

When some users fall victim to a phishing attack, which many will, backup layers of security should be ready to step in and fill the gap. Implementing multi-factor authentication where feasible adds an additional layer of protection in the event a privileged password is compromised. Even if a malicious application like a keystroke logger is installed, the phishermen will still only have half of the required credential information, as solutions like RSA SecureID automatically rotate a unique token code for authentication.

It is also understood and acknowledged that implementing multi-factor authentication isn’t feasible directly on all systems, and in that case, organizations should be utilizing the last and most effective line of defense, a privileged account management solution. A fully featured PAM solution can act as a gateway for the systems, by requiring a multi-factor login in order to fetch the current password. PAM solutions can automatically and regularly rotate personal and shared privileged account passwords, allowing companies can stay ahead of hackers. Target systems can be further protected by requiring users to connect directly from the PAM solution, using a built-in jump-server (such as the CyberArk’s Privileged Session Manager – PSM). A PSM-style solution can record user activity, and at the same time isolate the user’s potentially compromised machine from directly propagating the virus onto the server environment.

CyberSheath’s engineers are well versed in financial industry regulations and government standards and can help establish an effective Privileged Account solution appropriate for your organization. You can learn more about our approach by viewing our Privileged Access Management service area.

On April 27th, the European Commission signed into law the General Data Protection Regulation (GDPR – Regulation 2016/679 and 2016/680) that will serve to unify 28 (now 27 with the Brexit, perhaps) different privacy laws into one unified regulation applicable to all. The regulations, which are set to go into effect in May of 2018, will require widespread standardization and unification of data privacy requirements across EU member states.

Why should the US and other non-EU citizens or companies pay close attention to the further development in policy and standards taking place in Europe? Because it is clear that not only the business world of the European Union stands to be impacted, but all organizations, directly and indirectly, marketing to and processing information of EU data subjects, which includes most cloud-companies and a vast number of large enterprises.

GDPR will trigger much stricter guidelines and regulations for fundamental issues such as individual profiling, consent for data collection, and comprehensive definitions of data. Another notable change is that all breach notifications will be strictly required to be reported within 72 hours from the time of initial discovery. Not many countries currently have such regulations revolving around breach reporting. Although in the US, rapid reporting of cyber incidents to the DoD, in the exact same timeframe of 72 hours, is in fact already required by DFARS – Defense Federal Acquisition Regulation Supplement, which provides specific regulations for DoD government acquisition officials and all contractors doing business with the DoD.

In short, a greater significance will have to be placed on understanding exactly where all data is located, how and where it flows, where it resides, with whom it is shared, and what consents are or are not given and when it (data) must be purged.

There is a number of transitional questions that will need to be answered in the next two years.  What is the depth of impact to businesses and organizations worldwide? What unforeseen consequences will come to the IT world in general?

Organizations will have to pay close attention and stay connected to learn about the progression of the GDPR, as well as all other related data protection initiatives. It will be essential to understand the types of data protection (such as encryption) required by GDPR and to have a solid grasp on the types of platforms on which customer data is processed.

So, will the existing security solutions prove sufficient in the light of the new standards and regulations? What will the new breach notification requirements mean to the affected businesses? How will all personal data be properly classified in a way that enables secure access across all major platforms?  One important thing to keep in mind as we ponder these questions is that GDPR is not just for Europe! It is, at the very least, for any and all organizations that process, collect, and use personal data relating to EU subjects. There will clearly have to be a significant amount of work performed in order to meet all the technical issues and challenges as we move closer and closer to GDPR’s full implementation. Undoubtedly, there will be a great need for trusted partners to help provide on-site support with specialized knowledge, data mapping, and classification to help deploy the right types of solutions and protection.

If you’re reading this blog, chances are, it’s your responsibility to understand and enforce your organization’s compliance with the latest PCI Data Security Standards. With the release of PCI DSS version 3.2, the PCI Security Standards Council General Manager Stephen Orfei explained that “PCI DSS 3.2 advocates that organizations focus on people, process and policy, with technology playing an important role in reducing the overall cardholder data footprint.” Privileged accounts and their management is the central point of where people, process, policy, technology, and security converge. It is no surprise then that the PCI DSS 3.2 standards spend much of their time stressing the importance of protecting privileged accounts.

A key change in the PCI DSS 3.2 standard is the requirement to implement multi-factor-authentication for administrators accessing cardholder data (CDE).  As Troy Leach, the Chief Technology Officer of PCI, explained “Multi-factor authentication requires two or more technologies to authorize a person’s access to card data and systems. Examples of factors include something you know, such as a password or passphrase; something you have, such as a token or smart card; or something you are, such as a biometric. Multi-factor authentication is already a requirement in the PCI DSS for remote access. The significant change in PCI DSS 3.2 adds multi-factor authentication as a requirement for any personnel with non-console administrative access to the systems handling card data so that a password alone is not enough to verify the user’s identity and grant access to sensitive information.”

The reality is that it can be a daunting task to implement Multi-Factor-Authentication on legacy CDE systems. For one thing, there may be dozens, if not hundreds of various systems that are cross-integrated together, and implementing MFA on all of them would be a monumental task. One solution is to implement an enterprise PAM Solution, which would require an MFA login, and would act as a gateway to the CDE. For example with a mature PAM Solution, such as CyberArk, an organization would require all administrators to log into CyberArk with their MFA credentials, and then connect via CyberArk’s Privileged Session Manager (PSM), which is a type of jump server, to the target CDE. The target CDE would simply have to require that all access comes from the PSM via firewall rules, quickly solving the MFA. In addition, a mature PAM solution can at the same time address other key aspects of the PCI DSS 3.2 requirement, such as:

  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
  • Requirement 7: Restrict access to cardholder data by business need to know
  • Requirement 8: Identify and authenticate access system components
  • Requirement 10: Track and monitor all access to network resources and cardholder data

CyberSheath can help you understand and meet your compliance objectives and requirements, contact us today.

Securities and Exchange Commission (SEC) Chair Mary Jo White bluntly told attendees of the Reuters Financial Regulation Summit in Washington D.C. a few short weeks ago that cybersecurity is the single largest risk facing the financial sector reports Reuters.  Despite “a lot of preparedness, a lot of awareness” among broker-dealers and investment advisors, Ms. White said, “their policies and procedures are not tailored to their particular risks.”  White further stated “we can’t do enough in this sector,” a statement proven by the coordinated malware attack that stole $81 million from Bangladesh central bank this past February.

Financial companies should be concerned. It has not been the only attack in recent history; the Vietnamese Central Bank lost over $1 million in a cyber-attack, and the Russian currency system was manipulated with another attack to change the ruble-dollar rate by 15% within minutes.  The multi-million and perhaps billion-dollar question is how can financial companies protect their assets? Cybersecurity is a multifaceted effort, layers upon layers of security; there isn’t a single tool that can protect everything, but by focusing on the main target, businesses can prioritize security.

If the objective is to siphon off money from a financial institution, cyber-criminals are going to target the privileged accounts that have access to the financial data. An estimated $14 trillion dollars in transactions occur every day in the United States. Applications and programs talk to each other and access information to make these transactions happen; they often use privileged accounts to do so. By infiltrating a financial institution with sophisticated malware, hackers can target the hardcoded plain-text credentials and accounts that have access to financial information, and then manipulate them to steal money and financial information, or cause havoc in general.

By implementing a secure method for App-to-App or App-to-Database communication, financial institutions can increase their security posture and reduce the risk associated with malicious software attacks. This is done by removing the need for hardcoded plain-text credentials in applications and replacing them with a utility that pulls passwords from a secure storage location.

The CyberArk Application Identity Manager acts as a credential provider for applications and works in conjunction with the Enterprise Password Vault and Central Policy Manager. Now every time an application authenticates to a database or another program, it pulls the credentials from the Password Vault. This makes it extremely difficult for hackers to steal credentials, as they’re not coded in plain-text anymore. In the event the external perimeter may become compromised, the keys to the kingdom won’t be.

Mitigating a top attack vector for cyber-criminals such as privileged accounts will greatly reduce the risk Mary Jo White referred to in May. Don’t let your financial institution be the next one in the headlines; let CyberSheath’s team of Privileged Account Management engineers help protect your financial institution’s most sensitive information.

You can learn more about our approach by viewing our Privileged Access Management service area.

The deadline of June 1 looms for the Department of Homeland Security to gather threat-based data regarding our nation’s critical infrastructure. According to Netgov.com, by September of this year, the DHS is tasked with putting together a plan to put that data to use.  This should come as no surprise to security analysts as the rise in critical infrastructure attacks in the media has become more prevalent since the New York Times published articles about Stuxnet and joint Israeli-American involvement. More recently, the world has seen cyber-physical attacks in Ukraine against its bulk-electric system, in the United States against a NY flood-control dam, and several weeks ago in Sweden against an air-traffic-control system.

Attacks against critical infrastructure pose arguably the largest threat to any state, including the U.S. Their interdependencies and complicated private-public sector partnerships make for quite the quagmire. The United States alone categorizes 16 different critical infrastructure sectors which they define as,

“assets, systems, and networks, whether physical or virtual, are considered so vital to the United States that their incapacitation or destruction would have a debilitating effect on security, national economic security, national public health or safety, or any combination thereof”

Department of Homeland Security

It would be difficult to make a suitable comparison of the impact of a single major critical infrastructure attack could have versus the data-breaches that occurred over the last few years; let’s just say all previous breaches would pale in comparison.

Since the critical-infrastructure was not designed with security in mind, it soon could become all-too-real. That’s because the cyber-critical infrastructure has been built on programmable logic controllers, industrial control and SCADA systems, simple devices that don’t know right from wrong, and security has always been an afterthought. While the DHS figures out what to do with all the data they’re collecting, public and private sector critical infrastructure owners and operators need to prioritize their security and ramp-up the protection of these systems.

Critical infrastructure utilities can be proactive by implementing security tools to lock down and harden the attack-vectors of the industrial control systems. Utilizing Privileged Identity Management and Access suites like CyberArk provide an all-in-one solution for critical infrastructure operators. This is achieved by restricting access to privileged accounts, securing remote access, real-time monitoring of sessions and systems, and automatic management of privileged identities, all while meeting Critical Infrastructure Protection standards and reducing cost. It’s no wonder why 40% of Fortune 100 and 20% of Global 2000 companies choose CyberArk to protect their assets and infrastructure.

With 100% of advanced attacks exploiting privileged accounts, implementing an effective Privileged Account Management solution is vital. CyberSheath’s engineers are well versed in Critical Infrastructure Protection standards; let the experts help you establish a Privileged Account solution appropriate for your organization. U.S. Cyber Command Commander and National Security Agency Director Michael Rogers said that it’s a matter of “when,” not “if” a cyberattack targets the critical infrastructure; don’t wait around to find out.

You can learn more about our approach by viewing our Privileged Access Management service area.

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. 

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.

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