Outsourcing Policies and Procedures

The first step is of any outsourcing is understanding the importance of developing risk-based policies and procedures to govern your outsourcing process.  As discussed in the FFIEC Guidance, "Risk Management of Outsourced Technology Services," a comprehensive risk assessment will consider how the outsourcing arrangement will support the institution's objectives and strategic plans and how the relationship with the vendor will be managed. Once that step is completed, utilizing policies and procedures to review and compare multiple vendor candidates will ensure a stable comparison field and a better understanding of risk between various vendors.  Using the same process enterprise-wide provides a path for ensuring both services and vendors in all areas of the institution are in line with the institution's overall business strategy and goals.

Vendor Due Diligence

Now you have sent out a Request for Proposal (RFP) or started conversations with several vendors related to the proposed product or service.  Now, what do you do next?  Due diligence can serve as a verification and analysis tool, providing assurance that the vendor meets the institution's needs.  Understanding how to spot the right vendor requires knowing what to look for.

• Review the vendor's corporate history, including qualifications, backgrounds, and reputations of company principals. Verify that the vendor and your institution are a good fit from a mission and business strategy aspect.
• Analyze the vendor's audited financial statements to ensure their financial stability.
• Evaluate the vendor's experience and ability in the industry, including institutions with similar size and operations to your institution.
• Request and review references from current users about the vendor's reputation and performance
• Review the vendor's technology and systems architecture. Verify that the technology requirements of the service and vendor are compatible with your institution.
• Look at the Internal controls, security history, and audit coverage of the prospective vendor.
• Assess the vendor's information security program and resiliency.
• Check for any legal and regulatory compliance issues.
• Review the vendor's Insurance coverage.
• Review the vendor's reliance on and management of subcontractors
• Evaluate the vendor's fee structure and incentives
• Verify with your IT Department that the technology requirements of the service are in line with your institution's current technology. Different vendor services may have very different requirements, so having your IT Department review all vendor information could help point you to the best vendor for your institution.

Contract Negotiation Time

Contracts provide you with the ability to clearly identify rights and responsibilities and address significant issues.  Financial institutions can feel like they must sign the vendor's contract as-is, especially when dealing with a big company.  However, you have the right to negotiate what is included in a contract.  In fact, this step may clearly indicate which vendor will best suit your institution's needs.  If a vendor is not willing to include what your institution has decided is integral language, you may choose to continue searching for a vendor that will.  Here are some important elements the contract should address:

• Scope of Service including a description of activities, timeframes for implementation, and assignment of responsibilities
• Security and Confidentiality concerns
• Internal controls such as system monitoring, notification requirements, records maintenance, and cybersecurity
• Requirements to provide audit reports (state specific types and frequency)
• Requirements to provide performance and financial reports (state specific types and frequency)
• Requirement to provide Business Resumption/Contingency Plans
• Resilience on subcontracting
• Choice of law and jurisdictional provisions for foreign-based third parties
• Compliance with regulatory guidance and applicable laws
• Right to audit and require remediation
• Indemnification, Insurance, Dispute Resolution and Limits on Liability
• Defaults and Termination
• Performance Standards including measurable standards, minimum service level requirements, remedies, and Service Level Agreements (SLAs)
• Notification standards for service disruptions, security breaches, significant changes to the contracted activities, etc.
• Data access, ownership, and license

Vendor Selection can be time-consuming and overwhelming.  But, using good outsourcing policies and procedures, understanding what to look for in vendor due diligence, and knowing the important elements to include in vendor contract negotiation will make identifying the best vendor for your institution a bit easier and more successful.

First, let's define vendor significance. Significance is about how much you rely on the vendor. How significant are they to your operations? A vendor could be insignificant, significant, or even critical. For example, a vendor would be critical if you absolutely needed their services for your business to survive, like your core provider. A vendor would be insignificant if their failure would have minimal effect on your business, such as your office supplies vendor. You could get by with a little bit of help from Amazon or Walmart until you got a new vendor in place.

Next, let's define vendor risk. When talking about risk rating relationships with vendors, we often hear the question: is it inherent risk or residual risk? I believe it's neither. When it comes to your vendors, what you are looking at is transferred risk. Transferred risk is not the level of risk the vendor has before they apply controls, and it's not even the level of risk the vendor has after they apply controls. Some people may describe the due diligence process as applying controls and feel like the risk level selected is residual after getting and reviewing those documents. Not at all. Instead, what you find in due diligence, combined with the vendor significance, gives you an accurate representation of the transferred risk. It is the risk your bank is taking on by being in a relationship with the vendor, as-is. However, if needed, there are other measures you could pursue to reduce the transferred risk, such as certain insurance or requesting the vendor to gain certain certifications.

One thing to note is that significance and risk are not necessarily correlated. Imagine a vendor that is insignificant, perhaps an office cleaning service. They are insignificant because (1) there are many companies to choose from and (2) if you had to go without the service for a few days, it wouldn't be particularly harmful to the bank. At the same time, this vendor could be considered high risk from a security standpoint. Their staff has more access than the average person to your documents and assets. If they allowed access to bad actors, or if they shared proprietary information, that could cause a lot of damage. There is a high risk, even though the vendor is insignificant.

Here's what it looks like when we put all the pieces together. First, you determine significance by considering if the vendor were to have a breach, be temporarily unavailable, or be permanently unavailable, would that be a problem for us? If so, they are significant or maybe even critical, depending on your criteria. 

Then, you can get more specific with those problems to determine what due diligence documents would be valuable to review. Here are a few examples. 

• If the vendor had a breach and that would be a problem, we need to review their SOC Audit Report to confirm they are considered secure by a qualified third party. 
• If the vendor was to be temporarily unavailable, and that would be a problem, then we need to see enough of their BCP or SLA to make sure they have plans to keep our service moving. 
• If the vendor was to go out of business and that would be a problem, we need to see their financials to confirm it looks like they are going to last a while. 

If these things are not problems for us, then we don't need to look over, or even gather, the related documentation because it's not going to tell us anything we need.

Finally, knowing how significant the vendor is to us and knowing how stable and prepared they seem to be, based on the data in their due diligence, we can accurately define the transferred risk we are getting into by being in a relationship with the vendor.  

Prepare the Definitions

The first step in simplifying a BIA is to define ratings, categories, and labels of any kind. Definitions are foundational to an effective analysis process.

Criticality Levels

Criticality Levels are necessary for defining which processes require more immediate attention than others. Consider creating a set of levels such as: Critical, Urgent, Important, Normal, and Nonessential. If you work for a smaller institution, you may find you need fewer level options.

The definition of each criticality level is its corresponding Maximum Tolerable Downtime (MTD). This is the amount of time your business can tolerate without the process. For Critical processes, you may only tolerate minutes, but for Nonessential processes, you might tolerate weeks.

Business Impact Categories

When considering the downtime of a business process, consider the ramifications this downtime may have on your organization. The kind of impacts which concern you will determine your categories. At a minimum, you should consider the Compliance, Financial, Operational, and Reputational impacts to your organization should be process be unavailable.

For each category, provide clear definitions for each rating. For example, consider the following impact level definitions for the Compliance category:

• Insignificant: Negligible compliance, contractual, regulatory, or legal concerns.
• Low: Potential for compliance, contractual, regulatory, or legal issues with minor implications.
• Medium: Confirmed compliance, contractual, regulatory, or legal issues with moderate implications.
• High: Major penalties and/or costs related to compliance, contractual, regulatory, or legal issues.
• Extreme: Extreme penalties related to compliance, contractual, regulatory, or legal issues (e.g., jail time for employees, closing of the institution, etc.)

Analyze Impact

Make a list of your business processes. Business processes are a combination of the people, resources, and procedures that achieve a goal, such as Accounting, Information Technology, Lending Operations, Cash Management, and Regulatory Reporting.

Review one process at a time. Gather a group of people who deeply know and understand the process and how the lack of the process could impact the institution in different ways over different periods of time. Identifying the impact level for each category at each timeframe allows you to determine the MTD for this process.

Example Analysis

Let's look at an example business impact analysis with the Mobile Deposit Capture process and the Reputational impact category. If a disruption to this process occurred, what impact would this have on the organization? Don't spend too much time thinking about why the process is unavailable. Knowing why a process is unavailable is irrelevant to how long your organization can tolerate going without it before the missing piece begins to affect the organization's mission, customer experiences, other business functions, or compliance requirements.

After one hour, the institution may have a few unhappy customers, but the impact would overall be Insignificant. Even after one day, the impact might still be Low. If the process was down for three days, clients may really start to notice and could be upset (Medium). After one week, the organization would likely have to do a lot of work to regain trust (High). If the process was unavailable for 60 days, the impact might be Extreme, as clients could be lost and damage our reputation with the community. See the image for an example of what the ratings could look like.

When this assessment is performed for each category, the level of tolerance can be identified before a disruption becomes too detrimental for the business. That is the process' maximum tolerable downtime, and thus, criticality level. In this example, perhaps the impact is generally low prior to three days, so this process is set as Important. This means, in the event of a widespread business disruption, other higher priority processes will be given attention before this one until the three-day mark is reached.

Override for Dependent Processes

Don't forget about process dependencies. This could completely override the criticality level you determine through the BIA process. If there is another process with a shorter MTD which depends on this one to function, you must shorten the MTD of this process to have it ready to support the dependent one. Another option would be to reconsider the relationship between the two processes or reconsider if the other process has an accurate MTD.

The mobile technology environment makes work easier and more functional than ever before.  Our mobile devices - including laptops, tablets, and smartphones - are highly transportable, making ubiquitous access to work data a simple task.  Not only that, but most of our personal devices have our preferences saved, making them more comfortable to use.  According to a recent survey by Dell, 61% of Gen-Y and 50% of 30+ workers believe that their personal technology tools are more effective and productive than those used in their work life.

We call this phenomenon BYOD - Bring Your Own Device. BYOD has both positive and negative aspects.  Efficiency and productivity are increased due to employee comfort and proficiency with their own devices; however, the introduction of mobile devices to your secure bank network can put your bank in a vulnerable security position. When you consider the number of employee-owned smartphones in use, and add in the growing number of mobile laptops now utilized by banks, you begin to grasp the sheer amount of sensitive data walking around in the world every day.  Dangers posed by malicious applications, viruses, and hacking suddenly become a much more viable threat. So, for your bank, the question becomes, "How do we incorporate mobile device use in our bank environment and still protect our bank and customer information?"

Risk Management

Risk management is a well-known concept for banks.  Like a bank, you are always weighing the risk of any program, asset, or action against the benefit.  Managing the risk of mobile devices and BYOD is no different.  Determining the risks and developing your controls relating to mobile devices will produce the most successful marriage of convenience and security.  

Policies

Written policies can provide a specific mobile device and BYOD requirements and reinforce security expectations to your employees.  Best practices, employee restrictions, and even legal issues should all be included in your policy. The following are best practices that should be incorporated in your Mobile Device/BYOD policy:

• Strong and unique passwords
• Locking devices with biometric controls
• Data encryption
• Bluetooth and wi-fi features disabled except when in-use
• Bluetooth set to non-discoverable
• Security software installation
• Data wiping
• Reporting lost or stolen devices
• Multi-factor authentication
• Operating and security software updating
• Termination provisions

EMM and MDM

Enterprise Mobility Management (EMM) and Mobile Device Management (MDM) solutions can assist and enforce secure policies, such as identity management and authentication procedures.

Secure Network

Utilizing a secure gateway, such as a VPN, when accessing sensitive bank information from unsecured locations outside of the bank firewall provides another crucial layer of security.  The encrypted connection helps ensure that sensitive data is safely transmitted. You can even limit what bank information is accessible from a home network to protect bank and customer information.

Training

Employee training allows you to communicate your expectations for what your employees should and should not do with their devices.  Require periodic training on the bank's Mobile device/BYOD policy to provide your employees with up to date information and relay the bank's emphasis on the security need for the devices.  The frequency of training also reminds the employees of any aspects of security they may have forgotten and reinforced the overall importance of security.  Training can incorporate policies, as well as best practices such as:

• Using caution when opening email and text message attachments
• Avoiding joining unknown Wi-Fi networks, especially public networks
• Maintaining social awareness when utilizing mobile devices in public places

Mobile device/BYOD use is a common corporate practice in our world, and the banking industry is no different. Good planning allows banks to enjoy increased employee productivity and manage risk. Considering those risks and creating multi-layer controls can empower your bank and its' employees to incorporate mobile device/BYOD use, protect your bank and customer data, and still be confident in your security posture.

We all know that Employee Security Awareness Training is a key aspect of your Information Security Program.  In fact, the FFIEC IT Examination Booklet Information Security 2016 states, "Training should support security awareness and strengthen compliance with security and acceptable use policies. Management should educate users about their security roles and responsibilities and communicate them through acceptable use policies."  We even know that training should focus on important issues such as end-point security, log-in requirements, and password administration guidelines.  But still, the question remains, "Do we really have to do Employee Security Awareness Training, again?" The answer is Yes, and here's why.

The truth is simple.  People are the weakest link.  A bank can have all the latest technology and systems in place, but their employees will always be the weakest link, as well as the first line of defense, in the security chain.   It only takes one employee out of a hundred to click on a link that introduces malware into your network.  Or one employee who answers a few seemingly innocent questions, and important credential information used to hack a loan officer's email is in the hands of a threat actor who can now demand a fraudulent wire transfer.  As humans, we want to be trusting, and the bad guys work hard to be convincing.  Training not only addresses the technology but also the human element when it comes to keeping your bank and customer information safe. Here are a few tools to help make that happen.

Annual Training is Not Enough

Think back to last year's security awareness training session.  Was it really long, with a lot of jargon and information overload?  Sitting through all of the required training at one time can be overwhelming, with too much information to remember.  A better approach is to have more frequent training, maybe monthly or quarterly, that is shorter but more focused and pertinent.  Ongoing, consistent training communicates the importance of the bank's security culture, while allowing employees to understand and retain the training objective.

Use Real-Life Situations

It can be hard to relate to national breaches or vulnerabilities, but bringing a security issue to a more relatable level can drive home a security point.  For instance, demonstrating how easily simple passwords can be hacked, or identifying what information can be stolen from a mobile phone with no security, is relatable and memorable.  Instead of stating facts about the last password weakness breach or telling employees which passwords not to use, scale the information to a real-life circumstance.  Which leads me to my last point.

Train a New Way

Security Awareness Training doesn't have to be boring.  Training can be interactive using role simulations, team cyber issue problem solving, even question and answer sessions.  Test for effectiveness and provide incentives for good outcomes. Getting your employees involved and identifying themselves as a part of the solution can rejuvenate your employee training program.  Work with your employees to generate buy-in and make them ambassadors of your security.  Create a re-energized Employees Security Awareness Training program by training your staff in new and better ways, and deploy your employees as front-line protection for your bank and customer information.

A good Security Awareness Program is integral to helping your employees understand your bank culture relating to security.  While management sets the tone for a commitment to security, the employee's knowledge and awareness play a primary role in protecting the bank, and customer information.  By providing relevant security awareness training, you are inviting your employees to participate in successfully protecting the confidentiality, availability, and integrity of the bank's information and information assets.  

A small percentage of companies supply mobile devices for their employees, but a vast majority of employees bring their own devices. The challenge many companies face is how to secure those devices to protect the sensitive information that is stored on the device or is accessible on it.

The key to ensuring security on these devices is to use a mobile device management solution. When employees need to have access to sensitive information, adding the device to the mobile device manager will require certain security policies to be enforced.

There are several solutions that can be used to enforce security settings. The most common is Microsoft Exchange ActiveSync. A few others include IBM MaaS360, Cisco Meraki Systems Manager, and VMware AirWatch. At a minimum, a mobile device management solution should enforce these settings:

Require a PIN

It is vital to prevent unauthorized access to devices that have sensitive or confidential company information on them. The simplest way to enforce unauthorized access is through a personal identification number (PIN).

PINs should be four characters at minimum, but six or more is even better. Many mobile device management solutions can prevent users from using simple passcodes (e.g., 1234, 0000). Most mobile devices can also use biometrics, which are an even stronger control than a PIN number.

Set an Automatic Timeout

Mobile devices should be set to automatically lock after a maximum of five minutes of inactivity. This will help secure devices that are left unattended.

Encrypt Devices

Some mobile devices come with built-in encryption, but some do not. It is best practice to encrypt all mobile devices and storage cards so that if it is lost or stolen, the information on them will not be accessible.

Implement Remote Wipe Capabilities

Another important feature that most mobile device management solutions support is the ability to remotely wipe a device. This is an important feature in the situation where a device is lost or stolen. The feature will allow you to delete the phone's memory, which helps ensure confidential information is not disclosed. Wiping the device will also delete any personal information, such as pictures and text messages, so ensure all employees are made aware that if they misplace a device, it will be wiped.

When implementing a mobile device management solution in a bring your own device environment, inform employees of the requirements for bringing their own mobile device. This can be done in the on-boarding process and through acceptable use policies. Train employees to promptly report lost or stolen mobile devices so that they can be remotely wiped in a timely manner.

Due to the nature of people staying connected to their work even when they are out of the office, the security aspect of using mobile devices cannot be neglected. Using a mobile device management solution will help greatly to ensure that security controls are implemented and that they are enforced consistently across devices.

First, what is an outsourced technology service? This is a service that provides technology solutions for your bank. This doesn't necessarily include all vendors who use technology to deliver their service to you, but instead those providing solutions to your technology needs. Ask this question to help determine if something is a technology service, "Would the bank be significantly affected if the vendor's services were temporarily unavailable?" I take "significantly affected" to mean: irreparable damage to the bottom line or customer confidence due to service disruption from any cause. Only if the answer to this question is yes are you likely looking at an outsourced technology service.

Second, where do we find guidance for due diligence regarding these kinds of vendors? The current answer: FFIEC Business Continuity Management Booklet. The FFIEC released a brand new version of the booklet in November 2019, previously titled the Business Continuity Planning booklet. For some history, in 2015, the FFIEC released an addition to the BCP Booklet known as Appendix J. This appendix offered information about the cross-section between the BCP Booklet (2008) and the Outsourcing Technology Services Booklet (2005). It discussed what BCP things you needed to know about vendors you are using to outsource technology services. Now the contents of this appendix, among the other appendices, are fully integrated into the booklet content. There's your indicator that vendor BCP documentation is important if there ever was one!

Guidance expresses three important things about your vendor's business continuity documentation, which also provides direction on what your focus should be during your vendor review process.

Does the vendor maintain documentation of their business continuity management?

Vendor preparedness is key to your ability to maintain business as expected. Ensure the vendor has some kind of official documentation that both exists and is updated. There are several important elements to look for to confirm they will be able to deter and recover from cyber incidents: data backup, data integrity controls, alternate communication providers, layered anti-malware strategy, disaster recovery plan, incident response plan, and prearranged forensic and incident management services. Ideally, documentation for each of these elements will be included in as part of the vendor's business continuity documentation. If you don't see it, be sure to ask about it.

Are the vendor's Recovery Time Objectives and Recovery Point Objectives sufficient for the services contracted to your organization?

Know when the vendor intends to restore service to you after a disruption (RTO) and how much data they are willing to lose (RPO). Before you begin working with a vendor, know what their recovery expectations are and be sure they meet your expectations. If you are willing to be without service for 60 minutes, ensure they will have service restored to you in 60 minutes or less. If you are giving a BCP summary that doesn't include RTO and RPO, insist on getting the information. You may also find it as part of the contract, service level agreement, or even in a SOC report in some cases.

What does the vendor do for BCP testing?

Critical services should be tested, at least, annually. Be sure the testing includes the services you receive. Just because a vendor does testing, that does not guarantee the service provided to you was considered during that testing. Be sure to see enough details that you know their test scenarios include plausible significant events. A small hiccup is not what you are concerned about, nor the zombie apocalypse. Think plausible, like a hurricane near the coast, and significant, like something that takes out their entire headquarters. If any gaps in the plan were found during testing, then ensure you will have documentation of their remediation plans and the status of those changes.

Vendors are an extension of your bank, and especially technology services. It is wise to be diligent in gathering, reviewing, and confirming their plans for business continuity to protect you and your customers.

There is certainly a degree of overlap or redundancy among each of these three strategies, but each has its place in an organization's planning and preparing regimen, and each addresses its own collection of unique considerations. Those responsible for maintaining their financial institution's information security program must have a clear understanding of each of these aspects of continuity planning, recognize their similarities and differences, and be able to integrate each into a comprehensive strategy for addressing interruptions in their organization's processes.

Though interpretations vary and often turn into little more than semantic debates, some generally-accepted distinctions may be made. One factor by which to evaluate the differences between disaster recovery, business continuity, and incident response may be that of the scope or scale of the particular events the plans address.

Business Continuity

Business continuity planning is the process of developing a comprehensive written plan that addresses recovery from interruptions in business processes at a detailed level. An organization's business continuity plan will typically comprise a substantial document based on thorough risk assessments, prioritization of business processes, analysis of maximum allowable downtimes and other recovery timeframes, and much more.

An organization's business continuity plan is an umbrella of sorts. It considers all aspects of preparing for, mitigating against, and responding to reasonably foreseeable interruptions in business processes. It can serve as a playbook that details each person's roles and responsibilities in recovering from all kinds of business disruptions, including such events as power outages, connectivity disruptions, biological pandemics, or branch closures.

Disaster Recovery

Disaster recovery planning has a much broader scope, taking into consideration such calamitous events as hurricanes, earthquakes, and other large-scale service and infrastructure disruptions. A disaster recovery plan is concerned with restoring at least minimal operational capacity after a catastrophic or otherwise substantial loss, and is necessarily less granular than a business continuity plan.

Whereas the business continuity plan is developed using an in-depth, risk-based approach that is specific to the organization's business processes, disaster recovery planning must instead take into consideration events that have little or nothing to do with the financial institution's particular processes or operations. To put it another way, a tornado does not care about the significance of your vendor relationships or the controls you've put in place to mitigate the risk of malware infections.

Incident Response

Incident response serves as a point of contact or commonality between business continuity and disaster recovery. While business continuity and disaster recovery planning encompass the relatively broad scopes of general operational continuity and major catastrophic events respectively, incident response planning instead addresses particular, discrete, time-based incidents that may occur in the course of any disruption of an organization's operations. It is the development of tactical, systematic response and recovery procedures for specific events such as man-in-the-middle or denial-of-service attacks on your network, unauthorized access to sensitive assets or information, power outages, or any other particular event that has affected your organization.

An incident response plan may be a subset of either your business continuity plan or your disaster recovery plan, depending on the scope and nature of the event that has occurred. For example, if the event is merely a half-day power outage, your incident response may fall within the context of business continuity – just keeping operations running in the face of the event. Alternatively, if the event is a major disaster such as a tornado or other widespread infrastructure breakdown, you may have to execute multiple incident response plans in the course of a more broadly-scoped disaster recovery effort.

Business continuity, disaster recovery, and incident response planning each play an important role in an organization's preparedness program. Though there are certainly similarities between the three, it's important to be aware of the differences that make each strategy unique and needed. The absence of any of these three considerations renders an organization's continuity planning incomplete and increases the risk of delayed, incomplete, or ineffective responses to operational interruptions, large-scale disasters, and other disruptive events. It's important that those responsible for developing their financial institution's information security program recognize the roles each of these strategies play, and ensure they are integrating each into their organization's continuity planning program.

Problems arise[JS1], however, when users aren't trained to rely on easy to remember passphrases [JS2] such as "Passwords are lame!" but instead cling to the traditional "P@ssword01!" nonsense words that are difficult to remember, especially if users are correctly instructed to not write them down and the organization has not implemented password managers. The problem seems to worsen the more often passwords are changed. To address these issues, the National Institute of Standards and Technology (NIST) released Special Publication 800-63B[1].

Now, before the happy dance starts and password policies are updated to never require a change or enforce complexity, be aware that 800-63B contains recommendations, indicated by "should" and "should not," as well as strict requirements, reflected by the use of "shall" and "shall not." [JS3] In other words, there are loose guidelines, much like the "code" in the much loved first Pirates of the Caribbean movie (we won't mention the others[JS4] ), and rules that must be abided by for the standard to be met. Research into the recommendations will be left to the reader, but some of the important requirements are listed below (emphasis NIST):

• Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.
• Memorized secret verifiers SHALL NOT permit the subscriber to store a "hint" that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing memorized secrets.
• When processing requests to establish and change memorized secrets, verifiers[JS5] SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
  • o Passwords obtained from previous breach corpuses.
  • o Dictionary words.
  • o Repetitive or sequential characters (e.g. 'aaaaaa', '1234abcd').
  • o Context-specific words, such as the name of the service, the username, and derivatives thereof.
• Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

A quick review of the requirements would probably indicate that the first two items are easy to adopt, assuming they aren't already in place. After all, most organizations are requiring at least 8 characters, if not more, and have done so for several years. Additionally, most Windows login screens do not list a password hint, especially in a business setting. It is the last two items in the list that will create the greatest obstacle to using the updated NIST guidelines in a standard work environment.

First, there must be a way to compare the user passwords to a list of known dictionary words, passwords obtained from other breaches, etc. and do so DURING password creation. Doing this requires software that ties into Active Directory and has configurable policies and word lists. While a specific product will not be recommended here, two commercial offerings that come to mind are nFront Password Filter[2] and Anixis Password Policy Enforcer[3]. Standard vendor due diligence applies to either of these options, and any others discovered during a Google search.

Second, once passwords have been set, they should not be changed UNLESS there is evidence of compromise of the authenticator. The simplest method that comes to mind for most organizations is to periodically dump user password hashes and compare these hashes to large rainbow tables, such as the list of 555 million (yes, million) breached passwords hosted by the haveibeenpwned.com creator, Troy Hunt[4]. This list can, and should, also be used to check new passwords before the change is applied.

If an organization is willing to invest the [JS6] time and money into implementing the last two requirements above, and the changes do not go against any regulatory guidance by which the organization must abide, then a brave new world of no scheduled password changes and no password resets, will open up. If not, then the NIST guidelines cannot be adhered to and the same old settings must remain in place.

[1] https://pages.nist.gov/800-63-3/sp800-63b.html

[2] https://nfrontsecurity.com/products/nfront-password-filter/

[3] https://anixis.com/products/ppe/default.htm

[4] https://www.troyhunt.com/pwned-passwords-version-5/