Information Technology professionals typically view Data Loss Prevention in a rather narrow way: DLP is a set of tools, products, and/or practices that can be used to monitor for or restrict the transmission of sensitive data outside of a given organization. Operating under this assumption, Data Loss Prevention can be an excellent (albeit potentially expensive) way to keep sensitive firm information confidential. In a somewhat different view from industry professionals, the SEC has taken a considerably more expansive view of DLP in its 2015 Cybersecurity Examination Initiative.

OCIE, in this document, has listed Data Loss Prevention as a focus area and states:

Some data breaches may have resulted from the absence of robust controls in the areas of patch management and system configuration. Examiners may assess how firms monitor the volume of content transferred outside of the firm by its employees or through third parties, such as by email attachments or uploads. Examiners also may assess how firms monitor for potentially unauthorized data transfers and may review how firms verify the authenticity of a customer request to transfer funds.

In essence, the SEC has taken a large chunk of the NIST Framework, specifically the Protect Function, and called it Data Loss Prevention. Right, wrong, or indifferent, the Investment Adviser is faced with addressing the Commission’s expansive view of DLP. Each of the items that are listed as “may be reviewed” by the SEC warrant an in-depth look, but for the purposes of this post, we will try to give you some ammunition for each item:

Patch Management – Patch management has long be the domain of your network administrator. The SEC has brought this risk out of the tech silo and into your purview. It is not necessary to understand specifically HOW patches are applied across your network. What is important here though it that they ARE applied, and done so REGULARLY. Your firm should have written procedures, at a minimum, that surround the following:

  • Desktops/Laptops/Workstations – Most firms automate these updates, but you should consider how updates are applied to those systems that leave your network. Laptops that travel are often at the highest risk of infection from viruses or malware, as they are likely to be connecting to hotel networks, coffee shop networks, etc. (no matter how much IT tells the users not to!) Your firm should have a written plan for addressing and patching these systems that takes into consideration they may not be available for patching the day an update is rolled out.
  • Servers – Internal servers are typically patched on a less-frequent basis, as updates can cause problems from time to time. That is NOT a reason to let patches sit, unapplied, for any period of time. Similar to your User System Patching, servers should be patched on some formalized (and documented) timeline. It is ok to patch in the middle of the night on the weekend, in case there is an error, but your process must be repeatable and not allow any updates to slip through the cracks.
  • Application Patching – Keep in mind that any non-Operating System applications your firm uses may have their own update processes. Ensure that you have a system in place for patching these, especially items like Java and Flash that are historically weak from a security standpoint. If possible, these items should not be allowed on your network, but if there is a business case, make sure they stay patched! We have heard that certain vendors require the use of obsolete OSes or Versions of unique software. If you absolutely HAVE to run this software, it should be clearly noted as a deficiency in your third party due diligence, and compensating security controls should be put in place on those systems that require such obsolete, vulnerable software.

System Configuration – This seems to be something of a catchall that the SEC can use in the event of a breach. Theoretically, if any system is properly configured it should be reasonably expected to thwart an attempt to exploit it, unless there is an unpatched 0-day vulnerability. With that said, there are some simple items that your firm should be considering:

  • Supported OSes – It goes without saying that you firm can run any OS that it chooses, so long as it is supported. Windows XP should not be utilized unless there is a specific, necessary reason for its continued use. In this example, we would recommend that the system be isolated for use only for the particular reason it is needed, and not for general businesses purposes. In addition, you should document this specific business need.
  • Services at Startup – Think of all the junk that comes on every new computer you buy. Most of it runs at startup, taking resources. This is a best-case scenario – some services may in fact be malware (We are looking at you Lenovo/Superfish). Proper configuration will disable and remove these services and potentially limit some vulnerabilities.
  • Uniform Configuration – Some firms are able to maintain some uniformity among the systems they run, ensuring that from an IT management standpoint they “look” the same, with the same hardware and software. This makes management of the network, including patching, easier. If your firm has a mishmash of hardware, that is ok too, just make sure that you have some process in place to ensure that the oddball or unique systems are still properly secured.
  • User Restrictions – Simply put, if a user does not need administrative access to their machine, they should not have it. Preventing users from installing and running non-sanctioned applications can help to secure your systems and network.
  • Everything Else – “System Configuration” is a huge category and could encompass just about anything. These 4 points are just a starting point for the conversation with your IT staff.

Traffic Baselines – Developing traffic baselines will require some level of network monitoring. This is a new recommendation from the SEC and is somewhat surprising in that it will typically require some hardware/software acquisition in order to adequately complete. The idea behind developing an idea of traffic baselines that you (or your IT staff) will know what your network looks like under normal circumstances. When traffic begins to deviate from those norms, you will be alerted and can respond appropriately. If you have not already, talk with your IT staff or consultant and determine if the hardware you have in place now allows for the development and monitoring of traffic baselines.

  • Unauthorized Data Transfers – Traffic baselines can help you detect unauthorized data transfers but noting as something (data) starts to head off your network. However, this often requires a tight tolerance for flagging traffic and can produce many false positives. So, we would not consider this to be an adequate preventative measure. . This notion is what DLP software exists for. Individual data and files can be tagged to prevent their movement off your network. In addition, specific record types (items matching a SSN xxx-xx-xxxx format, for instance) can be blocked entirely. If this type of system is not in the budget, consider preventing this type of transfer by hardening your systems, preventing the use of removable media, segregating sensitive data and limiting access to your network.
  • Customer Fund Requests – This is the SEC’s giveaway here. Your validation process for Customer Fund Requests should be bulletproof at this point. Do not accept fund transfer instructions via email without a separate out-of-band confirmation. Meaning that, if a client emails you requesting funds, you call them back on a previously communicated telephone number and verify their request. This is not foolproof but will go a long way to preventing the distribution of funds to unauthorized recipients. Most importantly, train your staff that it is OK to say “no” in the event something seems amiss with a customer request. Train on this notion, and document everything.

Beyond these SEC-mentioned points, keep in mind the common DLP attack surfaces of personal email and cross-platform applications and apps. Applying controls to these well-worn paths for data exfiltration is often a low or no cost proposition for network administrators or the Compliance hero willing to take on the political fight.

Addressing Data Loss Prevention is but a start in the development of a robust cybersecurity posture that will secure your business and your customers today and in the future. At first, the request list can seem quite daunting, but if you break it down as we have attempted to do with one of the key groups, you can hopefully begin to address the regulatory checklist. The consensus is that if you are doing everything that the SEC is asking for in this list, you are in a decent place with respect to cybersecurity, at least for today. Remember: Cybersecurity is a moving target. You must remain vigilant and review your efforts regularly, modifying when necessary.