Categories
Computer & Network Security

7 Questions to Ask Before Deciding Whether to Pay a Ransomware Attacker

Intro

  • Ransomware is on the rise, owing to the pandemic. In 2020, ransomware exceeded $1.4 billion in the US alone, according to an estimate from Emsisoft.
  • Definition: When threat actors prevent a company from accessing their systems, network, or data until a demand is met.

7 Questions to Ask Before Deciding Whether To Pay a Ransomware Attacker

  • 1. & 2. Do You Have a Backup? Will it Work?
    • Today’s ransomware groups take backups into account. Even if you have backed up your critical files, it’s important to know the capabilities and functionality of your restoration services. If a threat actor has access to your backups, there is a good chance they will attempt to encrypt or even delete them. If you haven’t done so before and haven’t deeply investigated your capabilities, you won’t know how lengthy or difficult such a restore could be. You may also not understand whether there are backdoors in your restores or whether attackers have accessed any online backups.
  • 3. How Much Will the Ransom Really Cost You?
    • Many organizations wind up making the calculus that making the ransom payment is cheaper than losing data and/or business continuity. How badly does your company need the impacted system or the data stored on that system? if the machine is integral to business operation? There is also a cost to public perception and reputation. Paying ransoms may cast your organization in a negative light.
  • 4. Do I Call Law Enforcement?
    • Statistically speaking, law enforcement faces a low chance of catching ransomware groups. They also may not have the capacity to crack encryption or obtain decryption keys. However, that doesn’t mean there’s no utility to the act. One may reach out to law enforcement because it may be more likely the perpetrator will be caught, for the possibility that technical assistance from law enforcement may help, or because it helps show regulators and the public that you took all reasonable actions. It may also fulfil a requirement in cyber insurance coverage.
  • 5. Have You Considered the Risk of the Ransom Being Reneged?
    • Threat actors must maintain credibility in their claim that receiving the ransom payment will restore the victim’s systems. For the most part, that’s been the case, but further deception has occurred on more than a few occasions (Such as demanding another payment). Given that possibility, it’s in your interest to speak with ransomware experts about how your particular group has handled ransom payments.
  • 6. Have You Considered Law Enforcement Guidance?
    • Anyone who’s seen an action movie knows that the US doesn’t negotiate with terrorists. Perhaps surprisingly, the FBI doesn’t require or encourage not paying a ransom under any circumstances. What do they say?
      • “Whether to pay a ransom is a serious decision, requiring the evaluation of all options to protect shareholders, employees and customers. Victims will want to evaluate the technical feasibility, timeliness, and cost of restarting systems from backup.”
  • 7. Can You Forstall The Attack on Your Own
    • Ransomware attackers use many of the same methods as typical attackers. It’s possible that there’s guidance out there that could help you resolve the hack on your own. 
      • The “no more ransom” project, a collaboration between European law enforcement and cybersecurity companies Kaspersky Lab and McAfee, offers decryption tools for more than 85 ransomware varieties.

Conclusion

  • Deciding to pay a ransom or not is a difficult question to answer. Ultimately, it should be an informed and calculated decision based on due diligence and support from internal and external parties. However, if we want to do our part to try and curb ransomware attacks, we should design our systems and protect our organizations such that paying the ransom is left as a last resort.
Categories
Computer & Network Security

Best Practices for Privileged Account Management – Part 2

Privileged and Service Account Management

We spoke previously on the management of privileged accounts and how important it is to keep them accountable. Privileged accounts are one of many different types of accounts that should fall under your organizations Account Management Program and another one to add to that would be service accounts.

What is a service account anyway? In basic terms, a service account is an account that a service on your computer uses to run under and access resources. While they may look the same, the separation of users from services is very important for both tracking and the ability to tighten down what an account can do. A service account could also be an account that is used for a scheduled task (sometimes referred to as a batch job account), or an account that is used in a script that is run outside of a specific user’s context. A scheduled task account should not be a personal user’s account for the same reasons that a service should not run under a personal user’s account.

You may ask what is so important about these? It seems like if it is not a user account, then how would it have access to my organization’s network? On the contrary, these accounts are a favorite target of many malicious actors because they are often implemented in such a way that they have a higher level of access than a user account. These accounts are members of the domain in the same way a user account is. Historically, they also have not changed passwords as often (if ever) as user accounts.

Services are often installed under the built-in Local System account, which gives what are essentially local administrator privileges, so they are more predictable in how they will be able to be used if compromised. While local administrator privileges may seem somewhat harmless since they are not usually useable on other computers on your network, the local administrator privileges can end up granting access to domain username/password combinations. An attacker can use this as a jumping point  leading to account changes that allow for elevated access to other parts of your network. As a result, both locking down a service account and following good password change and audit procedures is an important part of keeping your systems secure.

What can you do?

When it comes to the configuration and management of service accounts, there a few things listed below that can help.

  • Password Management – Some administrators like to set these accounts up with passwords that do not expire or use the same password for all the service accounts. Instead, there needs to be a strategy for managing these passwords and changing them on a regular basis, as well as using unique passwords. Use an encrypted vault to protect, store and generate random passwords for service accounts.
  • Privilege Management – It is best practice to implement the principle of least privilege. Only provide the minimum necessary privileges to service accounts. If your service account must run with administrative privileges, deny that account access to all of the directories besides the one or two that it needs. Creating limited access to systems and denying interactive rights to only what is required reduces exposure.
  • Governance – First inventory all service accounts to know what you have and where. Next establish regular reviews of service accounts in the environment documenting ownership, required access and lifecycle of the account. Enforce these requirements with a workflow to gather these elements for new authorizations.
  • Auditing – Logging and auditing of service accounts, and all accounts in any case, is very important to keep systems secure. Using a SIEM looking for specific events can be helpful in discovering security problems and services that are not working correctly.

Locking down your service accounts should be a basic component of your hardening guide for all computers. While it requires more time to lock down a new service account to allow access only to what it needs, it is well worth the time spent. Defense-in-depth requires that you look at more than the perimeter, and service accounts are one major place where the in-depth strategy can serve you well.

 

Categories
Computer & Network Security

Best Practices for Privileged Account Management – Part 1

Basic Privileged Account Management

Abused and Misused privileges are often seen as being the cause of breaches within organizations around the world.  Privileged account management should be a major focus for Security and IT management who are looking to mitigate the risks of data breaches and insider risks.

What is Privileged Account Management?

Privilege Account Management is the definition and management of policies and processes that define the ways in which the user is provided access rights to enterprise systems.  It governs the management of the data that constitutes the user’s privileges and other attributes, including the storage, organization and access to information in directories (FICAM-09).  In other words, how an organization manages privileged passwords and delegates privileged actions.  Do you delegate, control, and filter privileged operations that an administrator can execute?  Do you audit, record, and monitor privileged access?

Why is it important to an organization?

When it comes to utilizing high business value IT systems, privileged users, such as administrators, typically have the widest operational latitude.  They are typically responsible for deploying and managing functionality on which the business depends, from vital day-to-day functions, to strategic capabilities that enable the business to maintain its competitive edge.

However, there are risks to wielding this power.  IT complexity means that minor changes could potentially have unintended, and severe impacts on availability, performance, and/or integrity.  Malicious attackers, inside and outside of the organization, can capitalize on administrative level access to inflict serious damage to the business.  Given the increasing sophistication and popularity of modern attacks via malware and other methods, it is common for attackers to gain and exploit such privileges by impersonating trustworthy personnel.

What are some common best practices?

There are countless solutions out there for organizations to implement and everyone has their opinion on what is the best way to do it.  Below are a set of common privileged account best practices all organizations should follow:

  • Separate regular access accounts from privileged accounts
  • Inventory all privileged accounts and assign ownership to that inventory
  • Do not use shared accounts
  • Minimize the number of personal privileged accounts
  • Limit scope for each privileged account
  • Use privilege elevation for users with regular access
  • Document policies and processes for the management of privileged accounts
  • Monitor and log all privileged access activity
  • Implement separation of duties model to manage superuser administrative privileges
  • Use default administrator, root, and similar accounts only when absolutely necessary
  • Require multi-factor authentication for all privileged accounts
  • Require complex and long passwords for privileged accounts
  • For service or application privileged accounts store passwords in an encrypted vault with a random password

Read Part 2 of this blog here >>.