Blog: Security

Multifactor authentication (MFA) is considered a staple in the world of security. For many, the use of MFA may seem straightforward, but as with many things in life, complexities abound. In this article, we will discuss five current challenges associated with MFA and ways to mitigate those risks. 

Before you go any further, visit this article over What is Multifactor Authentication? This article provides an overview of MFA, financial institution regulatory guidance sources, and tips for how to incorporate it into your information security program. 

Challenge #1. Misapplication of MFA may negate your cyber insurance. 

It is not a secret that cyber insurance companies are facing an uphill battle. Some sources state that in 2020, cyber insurers had a loss ratio of 500%, which means that for every $1 they earned in premiums, they lost $5 in responding to incidents. 

Due to the rising costs associated with cyber incident response, many insurance companies are beefing up their coverage requirements and now expect MFA to be enabled for the following types of services: 

  • All admin access (both internal and remote) to directory services, network backup environments, network infrastructure, endpoints, and servers. 
  • All remote access to the network, including employees and third parties. 
  • All email systems which can be accessed through a cloud service (e.g., Office 365). 

While this may seem like a reasonable request up-front, it may also be used as a reason to deny coverage in the event MFA implementation is not up-to-par. 

Facing the Challenge: Review your cyber insurance policies. Determine if they require MFA and if your current MFA implementation would be satisfactory in the event of an incident. 

Challenge #2. Financial institution guidance about MFA is not very descriptive. 

Various financial institution regulatory agencies and industry leaders also now expect multifactor authentication to be implemented, as discussed in this article over What is Multifactor Authentication? For example: 

  • FFIEC Authentication Guidance (August 2021) 
    According to the guidance, MFA is encouraged for "high-risk users," which are defined as users who have "access to critical systems and data; privileged users, including security administrators; remote access to information systems; and key positions such as senior management" (page 5). For additional information, read the full guidance
     
  • FFIEC Cybersecurity Assessment Tool 
    The following maturity declarative statements from the tool's "Access and Data Management" component include reference to multifactor authentication.
     
    • Remote access to critical systems by employees, contractors, and third parties uses encrypted connections and multifactor authentication. 
    • Multifactor authentication and/or layered controls have been implemented to secure all third-party access to the institution's network and/or systems and applications. 
    • Multifactor authentication (e.g., tokens, digital certificates) techniques are used for employee access to high-risk systems as identified in the risk assessment(s).
    • For additional information, download the PDF or sign up for Tandem's free automated version of the tool. 
  • CSBS Ransomware Self-Assessment Tool (R-SAT) 
    R-SAT Question 10 asks users to confirm that MFA is used for various circumstances, including access to cloud-based services, cloud email services, VPN remote access, and administrative access. For additional information, check out our R-SAT blog
     
  • NIST Cybersecurity Framework v1.1 
    While not specific to financial institutions, the framework references MFA in subcategory PR.AC-7, which states "users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction." For additional information, download the framework

While these guidance references are prescriptive, they are not overly descriptive as to how these recommendations are to be accomplished. 

Facing the Challenge: Implementing a control, such as MFA, needs to be focused on protecting likely entry points, in addition to those which could cause significant potential damage, if compromised. Start considering how MFA could most effectively be implemented to mitigate the risks facing your organization. 

Challenge #3. It is unfeasible to implement MFA everywhere. 

Perhaps the greatest challenge with MFA, especially in consideration of increasing requirements, is that it is currently unfeasible to implement everywhere. 

For example: 

  • It is not currently possible to enable MFA on Active Directory (AD) or SQL Servers. One can enable MFA on the systems which allow administrators to access these programs, but not the programs themselves, as they typically do not support integration with MFA applications. 
  • It is also not currently possible to enable MFA on service accounts. Service accounts often run with elevated privilege, but are not connected to any particular user, making it impossible to authenticate using MFA. 

  • To complicate matters further, there are multiple ways to authenticate as a Windows domain admin or to elevate privileges, once authenticated. Some examples could include running certain command lines, PowerShell scripts, windows management protocols, or User Account Control (UAC).  

While applying MFA everywhere may sound like a dream come true, technological limitations currently prevent that dream from becoming a reality. 

Facing the Challenge: Determine what you can secure with MFA and apply compensating controls for what you cannot. Based on your organization's long-term technology strategy, it may be beneficial to consider the possibility of moving certain systems to the cloud (e.g., Azure, AWS, etc.). That said, while many cloud solutions support MFA for access, they also present an entirely different set of risks and would not be a wholesale security solution in-and-of themselves. 

Challenge #4. MFA is not infallible. 

While MFA is an appealing control to consider, it is certainly not infallible and should not be implemented lightly. For example: 

  1. It is important to recognize that anybody who has administrator access also has the ability to turn MFA off. If you are depending on MFA as a security control for administrators, there must be validation implemented to ensure it is not disabled. 

  2. MFA is a preventive control. Unfortunately, this can mean that when MFA methods are incorrectly configured or fail to work, it can result in administrators being locked out of their systems, which could cause significant damage to the organization. 

  3. When controls, like MFA, cannot be implemented universally, it leaves the entire environment vulnerable by proxy. While applying MFA in certain areas or to certain users can limit exposure, the more security gaps you can close, the better. 

Facing the Challenge: Implementation of MFA is not only a technical decision. It is an enterprise-wide strategy. Start the conversation by including relevant personnel in the decision-making process. Assess the impact of MFA on operations and make sure plans are in place to limit negative consequences. 

Challenge #5. MFA can be expensive to implement. 

While MFA is becoming more widely available, implementing it can still require a significant investment of time and money, as "one MFA to rule them all" does not exist. Every system has its own form of MFA. For example, some systems support: 

  • Proprietary MFA solutions, such as Duo MFA, Palo Alto GlobalProtect, RSA SecurID, Symantec VIP, etc. 
  • Solutions built on the Time-Based One-Time Password (TOTP) standard, such as Google Authenticator, Microsoft Authenticator, Twilio Authy, etc. 
  • Native MFA solutions, built into the application, such as how the Tandem Mobile App can be used as an MFA option for Tandem access. 

Since systems use a variety of MFA options, it is up to each organization to ensure they select the right solution for them and ensure adequate coverage. 

Facing the Challenge: If you do not currently have MFA implemented, begin planning for it now. If you need assistance, there are managed security service providers (MSSPs) with expertise in this area, such as CoNetrix Technology. If you would like assistance with selecting and implementing the right MFA solution, contact us

Conclusion 

MFA is a highly effective control when it comes to reducing the risk of various threats, but it comes with its own set of challenges and risks. As you consider your current and future MFA plans, take a step back and answer the question: Are you trying to check a box or are you trying to mitigate a risk? 

A layered security program is always going to be the most effective way to face the cyber challenges of our time. While MFA is a helpful component of this program and should be used when feasible, it is not the only control you need. You have to use many controls to create a layered security program. For additional information about how you can secure your systems or to learn more about IT managed services, visit CoNetrix.com/Technology


 

The Federal Financial Institutions Examination Council (FFIEC) issued statements today notifying financial institutions of the risks associated with cyber-attacks on Automated Teller Machines (ATM) and car authorization systems and the continued distributed denial of service (DDoS) attacks. [more]

To read the Press Release, visit http://www.ffiec.gov/press/pr040214.htm

To view the Joint Statement, Cyber-attacks on Financial Institutions' ATM and Card Authorization Systems, visit http://www.ffiec.gov/press/PDF/FFIEC%20ATM%20Cash-Out%20Statement.pdf

To view the Joint Statement, Distributed Denial-of-Service (DDoS) Cyber-Attacks, Risk Mitigation, and Additional Resources, visit http://www.ffiec.gov/press/PDF/FFIEC%20DDoS%20Joint%20Statement.pdf


 

The Federal Financial Institutions Examination Council (FFIEC) jointly issued a statement to alert financial institutions Microsoft will discontinue extended support for Windows XP effective April 8, 2014.  After this date, Microsoft will no longer provide secruity patches or support for the Windows XP Operating System.  To read the Joint Statement, visit http://ithandbook.ffiec.gov/media/154161/final_ffiec_statement_on_windows_xp.pdf 

 

When working on a compromised system, it's always good to have a "toolkit" available on read-only media (in case built-in utilities, like netstat, have been replaced on the compromised machine to hide the attackers activities).  However, you also need to know how to USE the tools in your toolkit.  At my training last week I was working to recover a compromised web server.  After doing some cleanup and removing some clearly malicious software, I tried to use netstat to verify the current listening ports/services on the machine (along with associated processes).  The local netstat on the machine had been hacked to return no output, but thankfully the netstat EXE on my "toolkit" CD was working.  I quickly combed through the list of ports that were labeled "LISTENING".  I didn't see anything listening that was out of the ordinary.  However, when the following prompt popped up I knew the attacker still had remote access to my machine. [more]

Upon a closer look at the netstat output, I noticed there was an "ESTABLISHED" connection to TCP port 23 on my host (typically used for telnet).  P0wn3d!

Lesson learned… verify ESTABLISHED sessions in addition to actively LISTENING services.


 

A review of more than 200,000 4-digit PINs used on mobile phones revealed the following as the most common (in order):

  1. 1234 (used by more than 4% of the sample group)<
  2. 0000
  3. 2580 (straight down the middle of the keypad)<
  4. 1111
  5. 5555
  6. 5683 (spells LOVE)
  7. 0852 (straight up the middle of the keypad)
  8. 2222
  9. 1212
  10. 1998

The 10 most frequently used PINs represent more than 14% of the total sampled.  Thus, with this distribution of PINs, you have a 1 in 7 chance of guessing the correct one in 10 tries. [more]

Years are always popular when coming up with a 4-digit PIN (see number 10 above).  So, birth year, graduation year, etc. would also be a good guess if these are known

Regardless, it's a very good idea to recommend people NOT use these particular PINs (at least the first 9 plus predictable years).


 

I have received 4 or 5 email this week from a phishing scam that claims that one of my ACH transactions was recently cancelled. These emails are getting through the filters and landing in my Inbox. If you or anyone you know gets an email similar to the one below, delete it. I have modified the link in the email below so it won’t work, but you can still see where it was trying to go.

One indication the emails are fake – they purport to come from NACHA, the National ACH Association. However, NACHA does not deal directly with consumers or individual transactions.

If you know someone who works with payroll, purchasing, paying bills, etc., you should warn them about these emails. They are targeting people who work with online ACH transactions. Imagine the horror if the person responsible for payroll at a company received an email saying, “ACH Payroll Cancelled”. They would be very likely to click on the link first and think about security later. [more]

From: admin@nacha.org 
Sent: Friday, September 16, 2011 8:07 AM
To: You
Subject: ACH Payroll Cancelled

 
The ACH Payroll transaction (ID: 2150243623890),
recently initiated from your operating account (by your company), was rejected by the other financial institution.


Cancelled transaction

Transaction ID: 2150243623890
Reason for rejection: See details in the report below
Transaction Report: report_2150243623890.pdf.zip (self-extracting archive, Adobe PDF)

Note:
If you are sure that this email was delivered to you by mistake, please redirect it to your director or accountant.


..
13450 Sunrise Valley Drive, Suite 100 Herndon, VA 20171 (703)561-1100 2011 NACHA - The Electronic Payment Association


 

This approach is certainly not for everyone, but here is what I have done to mitigate the problem with so many certificate authorities out there.  The Comodo breach of March 2011, for example, allowed some bad guys to use a registration authority to generate valid certificates for Google, Yahoo, Skype, etc.  There are companies that sell boxes with software that will generate a valid certificates on the fly for every secure web site you visit in order to be able to observe your traffic.  With so many CAs, the risk of misuse has increased.  These comments mainly apply to Windows.

I think it was during May 2010, I edited the trust level on the root CA certificates in Firefox to only trust about 10 of them.  I think I have had to trust maybe two more since then.  I started with the list at http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas.  There are several links on this page that explain a lot about how Windows handles certificates.  This is one of the major reasons I use Firefox instead of IE.

To change the trust level of certificates in Firefox, go to Options, select the Encryption tab, and then the View Certificates button.  This brings up the Certificate Manger window.  The Authorities tab in the Certificate Manage window is where all the CAs are listed. Select each certificate and then select the Edit Trust button at the bottom.  This is where you can disable trusting each CA’s certificate. [more]

I also run the Firefox Addon Certificate Patrol which saves every certificate and warns me if a certificate has changed.  The primary blogger with the Tor Project, phobos (I don’t know the real name), suggests being your own certificate authority in a manual sort of way and not trusting any external certificate authorities (https://blog.torproject.org/blog/life-without-ca). I decided not to go that far.

If you prefer another browser such as Google Chrome or Internet Explorer, the procedure will be different.   Chrome and IE use the Windows certificate store, so you will have to delete the certificates that you do not want to trust.  Opera has it’s own store, but operates like Windows, downloading additional root certificates behind your back.  You may be able to preload these and remove the trust, but I have not taken the time to look into this.  I know nothing about how Safari handles certificates.

As I mentioned at the begining of the article, this approach is not for everyone.  However, for technical users with a little patience you can greatly reduce the likelihood you'll fall susceptible to a spoofed SSL certificate.


 

When people have cables with combination locks for securing their laptops at their workstation they always remember to turn the tumblers when they secure the laptop. But what happens when they unsecure the laptop? Many people won't turn the tumblers on the opened lock because it is much easier to lock the laptop later if the combination is already set.

In one instance, laptops were stolen by someone who came by when the laptops were not there and noted the combination. They came back later when the laptops were there and used the combination they had noted earlier.


 

Steve Gibson, one of the hosts of the popular "SecurityNow!" podcast, has created a tool that allows the checking of DNS servers for spoofability. This tool works by asking the user's browser to retrieve an image located at a uniquely named subdomain of the type xxxxxxxxxxxxx.dns.grc.com, "where the “xxxxxxxxxxxxx” is replaced with a unique 13-character string of characters that has never been used before."*

Then, in order to know the IP address for this special domain, the browser sends a DNS query to its DNS server, which then forwards this query to a special nameserver located at grc.com. This nameserver tells the DNS server that the location of that image is actually an "'alias' of the real domain name, which is a good deal longer and more complex."* The nameserver instructs the DNS server to look up the name of the "real" location of the image which looks like "...a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.xxxxxxxxxxxxx.dns.grc.com"* (with about 50 preceding 'a''s) [more]

The DNS server sends queries to the GRC nameserver, attempting to resolve the IP address of the given domain name one sub-domain at a time , causing the DNS server to send hundreds of requests which are collected by the GRC nameserver. As the nameserver collects these requests, it creates a scatter plot of both the Source Port and the Query Transaction ID of each request. Then, the data is analyzed to see the randomness of the Source Port and the Query Transaction ID which reveals the spoofability of the used DNS servers.

This tool is quite interesting, and shows that even as vulnerabilities arise on these critical systems, many do not fix the vulnerabilities, leaving the users at risk to visit a malicious web site believing that it is the site they were looking for which potentially places their private data at risk.

*A more thorough and detailed analysis of how this tool works can be found by reading GRC's article on how the DNS Nameserver Spoffability Test works.


 

I think we all know better than to download executable programs (.exe's) from untrusted sources and run them.  Opening a Word document from an untrusted source could be dangerous.  Now, even opening a PDF file on a fully patched Windows machine with excellent, up-to-date anti-virus and malware software could cause your machine to get owned.

Didier Stevens, who has written some great PDF analysis tools, published a disturbing blog post the other day.  He demonstrates how to use an existing feature in PDF to execute a program on someone's computer when they open the document.  Adobe Acrobat Reader displays a message first, but the message can be changed to social engineer someone into clicking the Open button on the message.  And my favorite PDF reader, Foxit, does not even display this message.  Disabling javascript does not help. [more]

Here is the link to his article: http://blog.didierstevens.com/2010/03/29/escape-from-pdf/

I downloaded his extremely simple example and in a few seconds changed it run a batch script instead of cmd.exe.  It looks it would be trivial to make it run any sequence of commands desired.  Depending on the PDF viewer used on other operating systems such as Linux or Mac OS X, this same technique will work there.

When using Google, one might consider clicking on Quick View or View as HTML instead of viewing the actual the PDF file.

UPDATE:  Adobe finally responded to this, explaining simply how to disable this feature.  This sounds like a good thing to do for most users. http://blogs.adobe.com/adobereader/2010/04/didier_stevens_launch_function.html