Skip to Main Content


You think patch management makes you "wanna' cry"? Try "not patching".


RANSOMWARE UPDATE: It happened again. Another ransomware attack hit very large corporations around the globe. Much like WannaCry, a worm spread through entire networks, and locked out encryption data and systems.

How did it work? A hacking tool known as EternalBlue (disclosed as part of the NSA’s leak on its hacking procedures) details how hackers may take advantage of a vulnerability in Microsoft Office products. The virus uses EternalBlue to spread through networks.

Here’s the kicker — Microsoft released a patch for EternalBlue in March. The ransomware attack could have been prevented if companies maintained and enforced requirements to be current with patches. As we see more of these attacks, remember to test system backups and your ability to restore systems from those backups. These backups will be critical if your organization falls victim to these or similar attacks. Restore your data, and make sure your systems are fully patched. For more information, get the Top 10 IT Security Risks E-book here.

The adage “You can’t afford to advertise, but you can’t afford not to” could well be applied to patch management. The  WannaCry/WannaCrypt ransomware malware attack that has spread across the globe has highlighted the need for keeping Windows OS up to date. Many organizations still underfund their patch management efforts and some still operate under the “I don’t want to be first” method of patching. This attack illustrates the need for swift patching. Exploits are coming out too fast to wait and see if the patch is safe. And for those still running Windows XP (unsupported since April 2014) it was just a matter of time before this happened.

Organizations and individuals that deploy basic and timely patch management techniques are protected from this attack. Microsoft released the fix in March of this year, before the exploit first showed up in April.

In this attack, ransomware is only half the story

The WannaCry code may have been able to work even on patched and updated computers, IF it had been installed correctly. Cybercriminals may target a specific organization and find ways to get the ransomware installed on internal systems, such as database servers. This can be done through social engineering techniques (e.g. tricking an employee to open an attachment or clicking a link in an email). But the criminal groups that deployed this attacked combined the ransomware with a worm that exploited a SMB vulnerability in the Windows operating system. The worm allowed the malware to spread through unpatched computers (desktops and servers) in over 100 countries.

Unfortunately, the vulnerability was allegedly discovered by the National Security Agency in 2014 but was never reported to Microsoft because the NSA and Central Intelligence Agency decided to keep the exploit as part of its cyber toolkit to spy on others. That toolkit was hacked, stolen, and made available for sale in April 2017 by WikiLeaks and a group called the Shadow Brokers.

Regardless of who carries blame, the bottom line is this disaster could have been prevented with basic upgrade and patching policies. Organizations that are hesitant to install patches for any reason may want to re-think this practice and base it on a realistic assessment of risks.

Patch management: no different from other important policies

Patch management should blend with other policies such as Backup and Recovery, Incident Response, and Disaster Recovery. Consider and assess the risk of applying patches as you would any other threat and plan for it accordingly. What you need to do:

  • Make sure the backup can recover the server in a tolerable amount of time (based on risk assessment or business impact analysis).
  • Perform backups before patching.
  • Include actions in your incident response and disaster recovery plans to recover a system impacted by a bad or improperly installed patch.
  • Invest in patching, backup, and recovery infrastructure at your organization (remember the “can’t afford not to advertise analogy).

Here are actions to take to protect you organization from the next WannaCry/WannaCrypt-style outbreak:

  • Block Server Message Block (SMB) ports, (particularly ports 139 and 445) from external hosts, along with User Datagram Protocol (UDP) ports 137 and 138, from the local network to the wide area network.
  • Keep anti-virus software up to date should be standard practice.
  • Whitelist the applications allowed to run on your servers or desktop using AppLocker or other white listing products.

No one security measure is foolproof. But patch management is an important and fundamental action and should be at the forefront of any organization’s layered security defense methodology. If you would like help analyzing your current patch management or security policies, our IT experts can share specific insights to help your organization.

Learn more about the top IT Security Risks for 2017.

Best practices for financial institution contracts with technology providers

As the financial services sector moves in an increasingly digital direction, you cannot overstate the need for robust and relevant information security programs. Financial institutions place more reliance than ever on third-party technology vendors to support core aspects of their business, and in turn place more reliance on those vendors to meet the industry’s high standards for information security. These include those in the Gramm-Leach-Bliley Act, Sarbanes Oxley 404, and regulations established by the Federal Financial Institutions Examination Council (FFIEC).

On April 2, 2019, the FDIC issued Financial Institution Letter (FIL) 19-2019, which outlines important requirements and considerations for financial institutions regarding their contracts with third-party technology service providers. In particular, FIL-19-2019 urges financial institutions to address how their business continuity and incident response processes integrate with those of their providers, and what that could mean for customers.

Common gaps in technology service provider contracts

As auditors of IT controls, we review lots of contracts between financial institutions and their technology service providers. When it comes to recommending areas for improvement, our top observations include:

  • No right-to-audit clause
    Including a right-to-audit clause encourages transparency and provides greater assurance that vendors are providing services, and charging for them, in accordance with their contract.
  • Unclear and/or inadequate rights and responsibilities around service disruptions
    In the event of a service incident, time and transparency are vital. Contracts that lack clear and comprehensive standards, both for the vendor and financial institution, regarding business continuity and incident response expose institutions to otherwise avoidable risk, including slow or substandard communications.
  • No defined recovery standards
    Explicitly defined recovery standards are essential to ensuring both parties know their role in responding and recovering from a disaster or other technology outage.

FIL-19-2019 also reminds financial institutions that they need to properly inform regulators when they undertake contracts or relationships with technology service providers. The Bank Service Company Act requires financial institutions to inform regulators in writing when receiving third-party services like sorting and posting of checks and deposits, computation and posting of interest, preparation and mailing of statements, and other functions involving data processing, Internet banking, and mobile banking services.

Writing clearer contracts that strengthen your institution

Financial institutions should review their contracts, especially those that are longstanding, and make necessary updates in accordance with FDIC guidelines. As operating environments continue to evolve, older contracts, often renewed automatically, are particularly easy to overlook. You also need to review business continuity and incident response procedures to ensure they address all services provided by third-parties.

Senior management and the Board of Directors hold ultimate responsibility for managing a financial institution’s relationship with its technology service providers. Management should inform board members of any and all services that the institution receives from third-parties to help them better understand your operating environment and information security needs.

Not sure what to look for when reviewing contracts? Some places to start include:

  • Establish your right-to-audit
    All contracts should include a right-to-audit clause, which preserves your ability to access and audit vendor records relating to their performance under contract. Most vendors will provide documentation of due diligence upon request, such as System and Organization Control (SOC) 1 or 2 reports detailing their financial and IT security controls.

    Many right-to-audit clauses also include a provision allowing your institution to conduct its own audit procedures. At a minimum, don’t hesitate to perform occasional walk-throughs of your vendor’s facilities to confirm that your contract’s provisions are being met.
  • Ensure connectivity with outsourced data centers
    If you outsource some or all of your core banking systems to a hosted data center, place added emphasis on your institution’s business continuity plan to ensure connectivity, such as through the use of multiple internet or dedicated telecommunications circuits. Data vendors should, by contract, be prepared to assist with alternative connectivity.
  • Set standards for incident response communications 
    Clear expectations for incident response are crucial  to helping you quickly and confidently manage the impact of a service incident on your customers and information systems. Vendor contracts should include explicit requirements for how and when vendors will communicate in the event of any issue or incident that affects your ability to serve your customers. You should also review and update contracts after each incident to address any areas of dissatisfaction with vendor communications.
  • Ensure regular testing of defined disaster recovery standards
    While vendor contracts don’t need to detail every aspect of a service provider’s recovery standards, they should ensure those standards will meet your institution’s needs. Contracts should guarantee that the vendor periodically tests, reviews, and updates their recovery standards, with input from your financial institution.

    Your data center may also offer regular disaster recovery and failover testing. If they do, your institution should participate in it. If they don’t, work with the vendor to conduct annual testing of your ability to access your hosted resources from an alternate site.

As financial institutions increasingly look to third-party vendors to meet their evolving technology needs, it is critical that management and the board understand which benefits—and related risks—those vendors present. By taking time today to align your vendor contracts with the latest FFIEC, FDIC, and NCUA standards, your institution will be better prepared to manage risk tomorrow.

For more help gaining control over risk and cybersecurity, see our blog on sustainable solutions for educating your Board of Directors and creating a culture of cybersecurity awareness.

Are your vendor contracts putting you at risk?

Who has the time or resources to keep tabs on everything that everyone in an organization does? No one. Therefore, you naturally need to trust (at least on a certain level) the actions and motives of various personnel. At the top of your “trust level” are privileged users—such as system and network administrators and developers—who keep vital systems, applications, and hardware up and running. Yet, according to the 2019 Centrify Privileged Access Management in the Modern Threatscape survey, 74% of data breaches occurred using privileged accounts. The survey also revealed that of the organizations responding:

  • 52% do not use password vaulting—password vaulting can help privileged users keep track of long, complex passwords for multiple accounts in an encrypted storage vault.
  • 65% still share the use of root and other privileged access—when the use of root accounts is required, users should invoke commands to inherent the privileges of the account (SUDO) without actually using the account. This ensures “who” used the account can be tracked.
  • Only 21% have implemented multi-factor authentication—the obvious benefit of multi-factor authentication is to enhance the security of authenticating users, but also in many sectors it is becoming a compliance requirement.
  • Only 47% have implemented complete auditing and monitoring—thorough auditing and monitoring is vital to securing privileged accounts.

So how does one even begin to trust privileged accounts in today’s environment? 

1. Start with an inventory

To best manage and monitor your privileged accounts, start by finding and cataloguing all assets (servers, applications, databases, network devices, etc.) within the organization. This will be beneficial in all areas of information security such as asset management, change control and software inventory tracking. Next, inventory all users of each asset and ensure that privileged user accounts:

  • Require privileges granted be based on roles and responsibilities
  • Require strong and complex passwords (exceeding those of normal users)
  • Have passwords that expire often (30 days recommended)
  • Implement multi-factor authentication
  • Are not shared with others and are not used for normal activity (the user of the privileged account should have a separate account for non-privileged or non-administrative activities)

If the account is only required for a service or application, disable the account’s ability to login from the server console and from across the network

2. Monitor—then monitor some more

The next step is to monitor the use of the identified privileged accounts. Enable event logging on all systems and aggregate to a log monitoring system or a Security Information and Event Management (SIEM) system that alerts in real time when privileged accounts are active. Configure the system to alert you when privileged accounts access sensitive data or alter database structure. Report any changes to device configurations, file structure, code, and executable programs. If these changes do not correlate to an approved change request, treat them as incidents and investigate.  

Consider software that analyzes user behavior and identifies deviations from normal activity. Privileged accounts that are accessing data or systems not part of their normal routine could be the indication of malicious activity or a database attack from a compromised privileged account. 

3. Secure the event logs

Finally, ensure that none of your privileged accounts have access to the logs being used for monitoring, nor have the ability to alter or delete those logs. In addition to real time monitoring and alerting, the log management system should have the ability to produce reports for periodic review by information security staff. The reports should also be archived for forensic purposes in the event of a breach or compromise.

Gain further assistance (and peace of mind) 

BerryDunn understands how privileged accounts should be monitored and audited. We can help your organization assess your current event management process and make recommendations if improvements are needed. Contact our team.

Trusting privileged accounts in the age of data breaches