Blog

By: (Security+)

How do you know what due diligence documents to gather from each of your vendors? There are many methods available, but some result in more accurate documentation than others. Today, I'm going to review two of the primary methods and discuss the effectiveness of each method.

Method #1: The Bucket Method

I often see, what I will call, the bucket method.

It Goes Something like This

Imagine you have a list of questions you ask about vendor characteristics, and then you classify that vendor based on the number of questions answered as "yes." For example, a vendor should be considered:

  • "Level 1" if two or less are answered as "yes."
  • "Level 2" if three to four are answered as "yes."
  • "Level 3" if five or more are answered as "yes."

Then, you could define the required due diligence based on the level of the vendor, or based on the bucket in which the vendor is grouped. At "Level 1," collect only a service level agreement. At "Level 2," collect a contract, a confidentiality agreement, and financial statements. At "Level 3," collect all document types (e.g., a contract, confidentiality agreement, financial statements, SOC report, examination report, BCP, etc.).

What Happens Now?

This method seems relatively simple to carry out. But in reality, it can create a lot of unnecessary document exceptions, and occasionally miss opportunities to request relevant documents.

  • Unnecessary Document Exceptions in a Bucket Method
    Consider a vendor who is "Level 3." While five characteristics applied to them, several of the required documents are both unnecessary to request, and at some rate, unreasonable. This results in an exception record to explain each case and ultimately, requires more effort from you, as the vendor manager, to oversee the relationship.

  • Missed Opportunities for Requesting Relevant Documents in a Bucket Method
    Consider a vendor who is "Level 2." While only three characteristics applied to the vendor, one of them is very important. If this vendor were to be unavailable for 24 hours, it would be detrimental for our business. We should get their BCP, but we did not because it was not required for "Level 2" vendors.
What This Means for You

The bucket method costs a lot of time and effort even though the labelling process seems quick and simple.

[Learn how to review your 3rd party vendor SOC reports in 15 minutes or less. Plus, download our free SOC review checklist.]

Method #2: The If-Then Method

Instead of the bucket method, consider the more accurate if-then method.

It Goes Something like This

Imagine you have a list of questions you ask about vendor characteristics. You could say that if you answer Question A as "yes," then you should collect a specific type of document related to the effects of that characteristic, Document A. Here are a few examples to consider:

  • If a vendor performs critical functions or provides critical services, then you should get a service level agreement.
  • If a vendor uses subcontractors in the performance of critical functions, then you should get their Third party Due Diligence of Subcontracts.
  • If a vendor stores customer information, then you should get a SOC report.

method for collecting vendor management due diligence documents

What Happens Now?

By using the if-then method, you only gather the documentation that is appropriate to the third party relationship. This method can be continually refined. If you notice you are creating a lot of document exceptions for a specific type of document, revisit the question you are asking that instigates this requirement. Consider what assumptions are being incorrectly made about the characteristic's effects. Update your list to appropriately account for this.

Let's say you thought, "If a vendor stores, transmits, or accesses customer data, then I should get their SOC report." You would quickly find that not every vendor who can access your customer's data is going to have a SOC report, and that the SOC report is quite unnecessary for the service you are receiving. In this case, you could create two separate questions. One question would be about storing customer data, in which you would require a SOC report. Then another about accessing and transmitting customer data, in which you would require a confidentiality agreement, but not a SOC report. Making this adjustment would greatly reduce the number of documented exceptions.

What This Means for You

The if-then method will eliminate unnecessary document requests and ensure pertinent documents are obtained.

In Summary

While both methods provide standardized ways to gather due diligence documentation from vendors, the bucket method can actually cause more problems for your vendor managers.  By using the if-then method, you can manage your vendors based on the services that are being provided to you and easily change your program to meet the developing needs of your environment. Couple this method with the Tandem Vendor Management Software, and increase the efficiency in which you conduct your program. 


 

By: (CISA, CISSP)

Early this year the tech world was rocked with the announcement of two unprecedented vulnerabilities named Meltdown and Spectre.

These two vulnerabilities are a big deal because they are hardware vulnerabilities affecting any device with a silicon chip. This includes microprocessors on workstations and servers, mobile phones, tablets, cloud services, and other platforms.

Understandably there was a rush from three main industries, processor companies, operating system companies, and cloud providers to provide solutions. However, as a result of the urgent response, there were unanticipated update incompatibilities which crashed systems. This created a dilemma for IT professionals. "Do we install updates which may cause our systems to crash?" or "Do we sit-tight and remain vulnerable?"

Even in the weeks of uncertainty, there were calm voices of seasoned reasoning. Their message reminded us that basic security standards remain our first line of defense. No matter how bad an exploit may be, its impact can be limited if:

  • The vulnerability doesn't have access to your systems
  • Operating system or application weaknesses are patched
  • Security software is installed (advanced end-point protection software with artificial intelligence is a game changer)

So how do you do achieve these standards? Here are some fundamental best practices:

  1. Monitor availability of operating system and application updates. Be sure you find and establish good sources to inform you about the patches and updates for your systems and applications. Then, monitor the sources or subscribe to notifications.

  2. Test updates to ensure compatibility. It is best if your update and patching process includes a test environment where non-production systems are updated first in order to test functionality and compatibility. This allows you to postpone or avoid updates which might crash systems or applications.

  3. Apply updates and patches on a regular schedule. As a best practice, you should implement a schedule (at least monthly) to evaluate, test and install updates for systems and critical applications. In this way, your schedule can coincide with schedules of operating system and application vendors (e.g., Microsoft has "Patch Tuesday, the second Tuesday of each month).

  4. Install and maintain security software (e.g., antivirus software, endpoint security software, etc.). If possible, explore and utilize behavior based end-point protection software. This genre of software "watches" system behavior to notice and stop suspicious action.

  5. Prevent malicious code execution. The goal is to keep malicious code out of your network and systems. This is best accomplished with layers of security including Internet filtering, phishing detection, and security awareness training for system users. Security awareness is essential to help prevent users from falling prey to malicious emails.


 

One of our Technology customers recently migrated to a new AT&T WAN offering called AT&T Switched Ethernet – Network on Demand (ASE NoD). This is the most recent evolution of their metro Ethernet service with the addition of long-distance layer 2 connections.

What makes this "network on demand" is the ability to change bandwidth as needed through a web portal up to the physical Ethernet hand-off limit, typically 10Mb/s, 100mb/s, or 1Gb/s. The default rate for each of this customer's location was set to 20, 50, or 100Mb/s.

Since this is relatively new product we had several Gotcha's in the implementation:

  • The customer ordered 1Gb/s hand-offs which is only delivered on single-mode fiber. This required new optics or media converters for sites with router that had only UTP connections.
  • The actual bandwidth for billing is based on the Committed Information Data (CID) rate. Initially was set to 20Mb/s for most sites, which matched the price quoted by AT&T. We wanted to increase the bandwidth for one location but the portal did not allow any changes above the default CID. After several calls to AT&T we discovered there was a hidden internal maximum set at 20Mb/s. My guess is they are trying to protect customers from themselves. We had them change the maximum to the max handoff speed of 1Gb/s.
  • After fixing the issue above, the Ethernet Virtual Channel (EVC) for each site changed to 1Mb/s, but thankfully only in the portal. The actual EVC did not change. It took another series of calls with AT&T to fix this issue.

 

I have encountered issues on PCs that can't access CDs or flash drives that previously had removable media access restricted by either group policy or Symantec Endpoint device control. After the control restrictions were removed, trying to read from the CD or flash drive gave an "Access Denied" error.

The only way I've been able to resolve this issue is by going to the Device Manager, uninstalling the CD-ROM drive/flash drive, and then scanning for hardware changes to add it back.

My assumption is that some registry settings aren't being changed correctly when policies are removed, so re-adding the device recreates the registry settings for the hardware.


 
 

Recently, Microsoft released a production version of a new management interface called Windows Admin Center, formerly known as Project Honolulu. The purpose of this product is to provide a centralized or locally-deployed management interface that will (eventually, hopefully) replace Server Manager. It manages servers by using Remote PowerShell or WMI over WinRM and client systems through similar methods.

Simply add your machines in the list, assign credentials to connect with (they can be your own – it doesn't appear credentials would be shared between administrators), and connect. The main requirement is that the server you're connecting to for management has WMF 5.0 installed.

As you can see from the above screenshot, there are a TON of things that you can do through this interface – including: browsing files, managing local users, managing the registry, enabling RDP, installing roles & features, managing and installing Windows Updates. It's a really impressive application that I plan to start using more often. It's very responsive and even loads interfaces faster than the MMC equivalent in many cases. I can certainly see the difference in the Event Viewer, for example.

To learn more or to download the free product, check out https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center

 

 


 

After installing each Windows 10 creator's update, I get the following error message when I try to click on any link in any email message or click on a table of contents link in a Word doc:

It's not an entirely bad thing to have email links require a copy and paste but it's a real problem with other links like the Table of Contents in a long Word document.

There is a KB article at https://support.microsoft.com/en-us/kb/310049 that discusses this issue. The solution for Windows 10 is to find a system that doesn't have the problem and export a registry key then import it into the offending system. The key it references gets deleted each time a new creator's update is installed.

HKEY_LOCAL_MACHINE\Software\Classes\htmlfile\shell\open\command

Then you export the subkey to a file, copy the file to the system having the problem and import it into that system's registry (either by double clicking the .reg file or importing it via regedit). There is a last verification step to verify the String (Default) value of "HKEY_CLASSES_ROOT \.html" key is "htmlfile".

That was several steps it took to make my system less secure. It's usually the other way around!

 


 

I was configuring a new Windows 10 PC for a customer and logged in under the local administrator account. I tried to open Edge but received a notification that Edge could not be opened by the built-in administrator account.

After some research, I discovered that Microsoft has become distrusting enough of the local administrator account that they prevent it from opening Microsoft Apps. This was actually introduced with Windows 8, but Windows 10 introduced Edge, which is potentially the first widespread use of Microsoft App.

The options to fix this are to either disable UAC, or adjust group policy to allow the local admin account to access Apps. The details of the issue and the options for a fix are included in this link: https://4sysops.com/archives/why-the-built-in-administrator-account-cant-open-edge-and-a-lesson-in-uac/


 

By: (Security+)

Ideally, reviewing a SOC Report will take you 15 minutes or less (once you get the hang of it). If you are a financial institution and you have vendors, then you have plenty of SOC Reports to review every year.

This blog will tell you what to review in SOC Reports, and nothing more.

You Don't Have to Know It All

I could tell you all sorts of information about SSAE 18 and SOC Reports! Here's one: SSAE 18 is the rule book and SOC is the engagement and report name, so you don't get a SSAE 18 from your vendor, you get a SOC Report. But what you actually want/need is a quick way to get your job done, not a dissertation on the inner working of SOC audits.

Other people may try to make the SOC Report review process seem big and complex so that you will rely on them to do the reviews for you… Don't let them scare you. You are capable of reviewing a SOC Report just as well as any expert. Really! I believe in you.

Admittedly, SOC Reports are complex and they are full of important information, but finding the information you need from it is really quite simple.

You Just Need the Important Parts

Think about this: If your vendor has a SOC Report, then that means an outside party has reviewed the vendor on your behalf. The outside party has verified the vendor is operating effectively. Thanks to this outside party, you don't have to comb over every detail of a SOC report. This means you can primarily read the cliff-notes version in the "Auditor's Report" section and trust the outside party's judgment.

SOC reports are completely standardized. They share a basic structure and even include some of the exact same sentences. This means you can grab what you need from a few specific places, then be on your way.

Let's Get To It

Here is a quick list of the information you need to find in a vendor's SOC report and note in your review. Section names won't be exact, but they're pretty close.

Look at the Cover Page to compile a profile for this SOC report. Find the company being reviewed, the auditing firm, SOC #, and Type #.

Look at the Scope subsection of the Auditor's Report section to find when the audit was done.

Now, this is one of the two most important parts of your review, so focus with me here. Look at the Scope subsection of the Auditor's Report section to see if complementary user entity controls are employed. If so, go to the Description of Systems section to find all of the details about the complementary user entity controls. And obviously, make sure you are doing those things.

Look at the Scope subsection of the Auditor's Report section to see if subservice provider controls are employed. If so, go to the Description of Systems section to find out what the vendor is doing to monitor the subservice provider controls.

Look at the Limitations subsection of the Auditor's Report section to see if anything happened during the audit that limited the auditor's ability to check everything.

This is the other of the two most important parts of your review. Look at the Opinion subsection of the Auditor's Report section to see if the auditor found anything problematic. Also note their official "opinion." If the auditor noted significant issues, find the Other section. Management should provide some kind of response to the significant issues found.

If this was a Type 2 engagement, look at the Test Results section to find any and all exceptions encountered during testing. This may include some that were not considered significant enough for the auditor to mention in the Opinion subsection.

And that's it. While it's pretty simple, why not make it easier? We created a downloadable PDF with the above checklist so that you can easily and efficiently review your SOC reports.

Vendor SOC Review Checklist Template PDF


 

In September 2016, the Federal Financial Institutions Examination Council (FFIEC) released an updated Information Security Booklet as part of the IT Examination Handbook. Among other contemporary concepts, the FFIEC placed an increased emphasis on the role of Information Security Officers (ISOs) in financial institutions. In section I.B Responsibility and Accountability (Page 5), the FFIEC provides a list of six key qualities of the ISO role. Here are the six qualities and a brief interpretation of how this can be applied in your organization.

1. Sufficient Authority

Each ISO should have sufficient authority to perform their assigned tasks. While the ISO ultimately reports to the board or senior management, they must also be a trusted employee (or group of employees) who is authorized to make organization-altering decisions on their own. In short, your ISO should be someone you can, and will, trust.

2. Stature within the Organization

Each ISO should have stature within the organization to perform their assigned tasks. In addition to being a trustworthy part of the organization, the ISO should also be a respected part of the organization. The role of the ISO is a position that should be held with esteem. This is a tone that is set from the top. If the board and senior management respect the role of the ISO, the organization's employees will respect it, as well.

3. Knowledge

Each ISO should have knowledge to perform their assigned tasks. The ISO is tasked with oversight of the information security program. This is a broad-scoped topic which requires knowledge of the physical, technical, and administrative functions of the organization. If no one employee has sufficient knowledge to make decisions for each of these areas, it may be wise to consider appointing multiple individuals to fill the organization's ISO role as a committee.

Click here to find out more about a 6 part webinar training series created specifically for ISOs.

4. Background

Each ISO should have background to perform their assigned tasks. Similar to knowledge, the ISO should have a history that involves information security. An employee can be trustworthy, respectable, and have knowledge of information security, but be lacking a foundation of experience. Information security is an ever-changing field. Appointing an ISO who does not have experience in the field is a risk to the organization's information security.

5. Training

Each ISO should have continued training to perform their assigned tasks. Since the field is ever-changing, it should not be assumed that the ISO has all the training required to perform their duty. As the threat environment changes, as new controls are implemented, as the industry advances, the board and senior management should expect the ISO or members of the ISO team to further their education through training.

6. Independence

Each ISO should have independence to perform their assigned tasks. It would be best to avoid conflicts of interest when selecting an ISO. For example, while knowledge of information technology (IT) is important, the ISO should not be the person responsible for implementing the organization's IT function. For community financial institutions, this is not always practical. So, if your organization finds independence difficult, it may be beneficial to appoint individuals from various departments to fill the organization's ISO role as a committee.

In Summary…

While the FFIEC may not be very prescriptive when it comes to appointing an ISO, by ensuring your organization's ISO is trustworthy, respectable, knowledgeable, experienced, interested in learning, and independent of other functions in the organization, your organization can lay the foundation for an effective information security program.