The Safe Systems Compliance Team – Page 5

19 Apr 2019

Hot Topics The Safe Systems Compliance Team 0 comment

Misuse, Denied Access, and Incident Response

It may be a good time to review your Incident Response Plan and determine if additional clarification regarding the term “misuse” should be added to incorporate denial of access to information. The FFIEC Information Technology Examination Handbook for Information Security was published in September 2016 and refers to misuse as “attacks from within the organizations”. This definition comes from internal employees accessing unauthorized information through improperly configured (or lack thereof) security controls. Due to the availability of ransomware and DDoS attack services, denial of access to critical information is becoming a more common risk financial institutions are facing.

The IT Examination Handbook defines distributed denial of service (DDoS) as “A type of attack that makes a computer resource or resources unavailable to its intended users”. Financial institutions that experience DDoS attacks may face operational and reputation risks depending on which resources were targeted in the attack. The FFIEC expects financial institutions to address DDoS readiness as part of their Information Security Program and Incident Response Plan.

DDos Readiness

The FFIEC Information Technology Handbook on Business Continuity Planning and Information Security booklets provide the following steps that should be taken to improve DDoS readiness:

Maintain an ongoing program to assess information security risk that identifies, prioritizes, and assesses the risk to critical systems, including threats to external websites and online accounts.
Monitor Internet traffic to the institution’s website to detect attacks.
Activate Incident Response Plans and notify service providers, including Internet service providers (ISPs), as appropriate, if the institution suspects that a DDoS attack is occurring. Response plans should include appropriate communication strategies with customers concerning the safety of their accounts.
Ensure sufficient staffing for the duration of the DDoS attack and consider hiring precontracted third-party servicers, as appropriate, that can assist in managing the Internet-based traffic flow. Identify how the institution’s ISP can assist in responding to and mitigating an attack.
Consider sharing information with organizations, such as the Financial Services Information Sharing and Analysis Center and law enforcement because attacks can change rapidly and sharing the information can help institutions to identify and mitigate new threats and tactics.
Evaluate any gaps in the institution’s response following attacks and in its ongoing risk assessments, and adjust risk management controls accordingly

The growing threat landscape and increased accessibility to ransomware and DDoS services encourage Information Security Programs and Incident Response Plans to constantly evolve to ensure financial institutions can effectively respond to these types of attacks. It’s important for your procedures to cover specific containment and remediation steps to quickly respond when your financial institution becomes the target of one of these attacks. We’re commonly seeing additional clarification in Incident Response Plans that moves the focus of misuse from internal threats, to a broader definition that includes the idea of denied access: “Misuse includes all unauthorized access to data, with or without data disclosure. It also includes unauthorized denial of access to data”.

25 Mar 2019

Financier Works on a Personal Computer Showing Statistics, Graphs and Charts. In the Background His Coworker and Creative Office.

From the Field The Safe Systems Compliance Team 0 comment

Asset Lifecycle Management

Since both Windows 7 and Server 2008 R2 will reach end-of-life support in January of 2020, many organizations have already made the jump to Windows 10 and Windows Server 2012, 2016, 2019, or Azure. If you have full control over the asset lifecycle management process for your financial institution you may have already completed this conversion and are working through the headache of teaching your end users the nuances of Windows 10. Because of the complexity of the conversion process (particularly at the server level), we have also started to see trends in outsourcing more information technology tasks to external technology service providers (TSPs). No matter where your financial institution may fall on this DIY to outsourced spectrum, it’s critical to have a well-defined asset lifecycle management process.

Defining Asset Lifecycle

Let’s start by unpacking asset lifecycle to understand why the process is so important that an entire contributing component within the FFIEC Cybersecurity Assessment Tool, and a section of the Information Security IT Handbook, is dedicated to IT Asset Management.

NIST condenses the typical asset lifecycle to three phases:

Enrollment
Operation
End-of-Life

Similarly, the FFIEC defines the lifecycle process as “The multistep process that starts with the initiation, analysis, design, and implementation, and continues through the maintenance and disposal of the system.” For the purposes of this article, we’ll use the 3-phase NIST definition, and assume that the enrollment phase includes initiation, analysis and design; operation includes implementation and maintenance; and end-of-life includes disposal.

The enrollment phase will include planning for new IT assets, procuring those assets, and configuring them for production environments. The operations phase determines how IT assets are maintained and the specific policies that provide structure for performing changes or modifications to them. As IT assets reach the end-of-life phase, they must be properly decommissioned and disposed.

If you’re working with a TSP in this area, this vendor will likely procure and pre-configure the new assets and may even perform the implementation for you. It is important to ensure the service provider is aware of your policies (including your IT risk appetite), and that they will abide by them and follow financial industry best practices. The TSPs should also be able to provide you with a baseline configuration, or checklist for the newly introduced IT assets, to prove that they have been pre-configured to your security specifications. Your own internal asset lifecycle management policy should include receiving this information from your TSP prior to new assets being implemented into your infrastructure.

Inventory Classifications

FFIEC guidance requires IT assets to be both inventoried and classified according to the type of data they will store or process. Classification should be tied to sensitivity and criticality. Sensitivity is typically expressed as private (customer NPI), confidential (non-NPI FI information such as HR records, strategic plans, etc.), and public. Criticality is usually inherited from the process the asset is utilized for, expressed as the recovery time objective for the underlying process.

As technology changes, we are seeing fewer barcodes for physical asset inventories, and more Excel spreadsheets comprised of printer, server, and workstation inventory information. Many TSPs provide an automated central management solution for assets that greatly reduces the overhead of manually managing so many devices. The routine (daily, monthly, quarterly) maintenance for IT assets should also be documented in the asset lifecycle management policy. These tasks are the NIST operation phase that provides documentation for software and OS patches, AV/Anti-malware, data backups, etc.

Destruction and Disposal

A lot of emphasis is placed on the introduction of new IT assets and the support and maintenance of them throughout their operation, but it is equally important to include destruction and disposal procedures for these assets as they reach the end of their lifecycle. When a system reaches End-of-Life it means that a vendor is no longer providing critical security updates or support for those devices, and any new vulnerabilities may be exposed to exploitation. If a TSP assists with decommissioning these devices, their disposal practices should be reviewed and determined to align with your own policies based on the classification or the assets and the retention period for the data. Any devices that house non-public or confidential information should be securely erased or destroyed to ensure the contents are not recoverable, and if this process is outsourced, the TSP should be able to provide validation of this process.

Occasionally, there is a legitimate business need to continue using hardware or software that has reached End-of-Life support. A risk assessment should be performed, and any compensating controls implemented and documented. If residual risks are still too high, this may include segmenting the asset from the rest of the network to limit the risk exposure.

Vendor Management

Whether your financial institution manages the entire asset lifecycle process internally, outsources it completed to TSPs, or is somewhere in between, it is critical to have a structured, well-defined plan that follows these assets from planning and implementation to decommission and salvage. If you outsource any aspect of this process, a robust ongoing vendor management program is critical in providing a level of assurance and in holding them accountable for their obligations throughout the asset lifecycle management process. Of course, with all things outsourced, you cannot outsource the responsibility.

Examiners

Appendix A of the FFIEC IT Handbook provides the examination procedures for establishing an effective lifecycle management policy. Examiners are instructed to do the following:

“Determine whether management plans for the life cycles of the institution’s systems, eventual end of life, and any corresponding business impacts. Review whether the institution’s lifecycle management includes the following:

Maintaining inventories of systems and applications.
Adhering to an approved End-of-Life or sunset policy for older systems.
Tracking changes made to the systems and applications, availability of updates, and the planned end of support by the vendor.
Planning for the update or replacement of systems nearing obsolescence.
Outlining procedures for the secure destruction or wiping of hard drives being returned to vendors or donated to prevent the inadvertent disclosure of sensitive information.”

18 Jun 2018

Best GDPR Practices for Financial Institutions

Ask the Guru The Safe Systems Compliance Team 0 comment

Ask the Guru: GDPR

Hey Guru!

I have heard a lot about GDPR recently, but I am not terribly familiar with it. I already break my back to stay in compliance with FFIEC guidance. Do I have anything more to worry about here?

GDPR has certainly been in the news for the past few months as implementation was required as of 5/25, but interpretations have varied as to how this will influence US-based entities with no real European presence. While it is still too early to know exactly how GDPR will be applied and enforced, the basic framework still leaves us with plenty to discuss.

The Basics

The General Data Protection Regulation was designed by the European Union (EU) member nations to create a uniform standard of consumer data privacy protection for all companies that do business in the EU. Think of this as GLBA with a few added features.

In the context of GDPR, protected parties (consumers) are called “data subjects”, any party in control of data (like a financial institution) is called a “controller,” and any entity that interacts with that data on behalf of the controller (like a technology service providers) is referred to as a “processor.” The regulation concerns itself with the privacy of EU citizen data. In this respect, it has the identical goal of GLBA.

The Scope

Naturally, GDPR applies to entities physically located within the EU member countries, but the regulation could, under certain circumstances, reach “across the pond”. Included are organizations based outside the EU that provide goods/services, or track the behavior of, data subjects within the EU.

In theory this COULD include your institution, but it’s a bit of a long shot. It really boils down to this: do you have any EU citizens, or dual US/EU citizens, on your list of customers/members? If the answer is “no”, then in all likelihood you can rest easy unless you are actively marketing to EU citizens.

Notable Rules

Financial institutions that are required to comply with GDPR have a head start. As I mentioned, many of the basic privacy and security principles of GLBA translate to GDPR; however, there are a few key areas where GDPR takes things a step further:

Right to be forgotten/Right to Erasure – EU citizens covered by GDPR have a right to request that any and all personal data you have on them be corrected (if inaccurate), or deleted entirely. A key note here is that this is only required if the individual makes such a request, and even then, the institution would have 30 days to respond. Since Core processors are likely to be your single largest data store of customer information, you may want to check with them on their GDPR compliance efforts. Other places this type of data might be located is email, including hosted email services (such as Exchange Online). Responding to a Right to Erasure request may be a bit tricky in a cloud environment, as email cloud companies would need to work with their 3rd party vendors to find and purge the email, as well as all backups and archives.
72 hour breach notification – If your institution experiences a breach, you’ll have 72 hours from that point to notify the supervisory authority in the member state in which your customer/member resides. GLBA does not have specific timeframes on notification actions, specifying instead that “…a financial institution should provide a notice to its customers whenever it becomes aware of an incident of unauthorized access to customer information and, at the conclusion of a reasonable investigation, determines that misuse of the information has occurred or it is reasonably possible that misuse will occur.”
Explicit Opt In requirements – This is where GDPR really deviates from GLBA. Essentially, EU citizens must both opt in to what information will be collected about them, and must agree to every way in which that data is used prior to those actions taking place. GLBA regulations are generally more reactive here, they allow institutions to default to an opt-in position, requiring notification to opt-out.
Contracts – Similar to GLBA, contracts with third-parties transmitting, processing or storing EU citizen data should spell out how the exchange and use of data will work with data processors, and for what, exactly, each party is responsible. In practice, this would just become a deeper dive during due diligence/on-going monitoring of your Technology Service Providers.

Enforcement

Let’s put things back in perspective. While GDPR provides for rather severe penalties for non-compliance, there is still the matter of enforcement. Even if EU regulators wanted to take enforcement action against a US financial institution – would they, and more importantly, could they?

First of all, the EU has made it clear they’re only going after the worst and highest profile abusers of the regulations. Since most US-based financial institutions do not have any direct business presence within the EU, and few if any EU citizens as customers/members, they just aren’t likely to be a target for EU regulators.

Second, it is very unclear how a US institution could even be sanctioned or penalized by EU supervisory agencies, even if the institution has EU citizens as customers/members and has run afoul of the regulations. Worst case is you’ll have to terminate your business relationship with the EU citizen.

In the meantime, we’re definitely going to keep a close watch on how (and if) the US financial regulators react to this, and act accordingly. Up to now they have been completely silent on this matter, which speaks volumes to me. So until then, I think you can rest easy, or at least easier!

30 May 2018

Ask the Guru The Safe Systems Compliance Team 0 comment

Ask the Guru: A Prospective Vendor Either Won’t or Can’t Provide the Documentation We Need. What Should We Do?

Hey Guru!

We’re doing our due diligence on a new HR software package. We’ve requested the vendor’s financials and a SOC 2 report, but they told us they don’t provide financials (they are privately held), and their SOC 2 won’t be completed until the end of the year. They do have a SOC 1. What are your thoughts on this?

As with almost everything else, this starts with the risk assessment. What are your primary concerns with this vendor? They probably fall in 2 main categories; the security of the confidential data they store and process, and the criticality of the service they provide. A sound set of financials will give you some assurance that they can continue as an on-going concern and fulfill the terms of their contract. A SOC report will give you assurance that they have an effective control system in place for your confidential data. SO without either, how do you assure yourself? You’ll need to find alternate assurances, otherwise known as compensating controls.

In the absence of audited financials, one way to gain at least some assurance about the financial health of the company is to pull a D&B report. Another way is to ask the company for their banking contact as a reference, but as a private company they may be reluctant to provide that. In the end, if you aren’t able to gain sufficient assurance of their ability to continue to function, you’ll need to identify alternative vendors that can step in if needed.

Regarding assurances of their control environment in the absence of a SOC 2 report, this is a bit more difficult because there are potentially 5 criteria covered in a SOC 2 report; confidentiality, data integrity, data availability, privacy and security. Their SOC 1 may speak to data processing integrity, but compensating controls for the other criteria will have to be pieced together. BCP plans and testing results can speak to data availability. InfoSec policies, vulnerability assessments and PEN test results can speak to the security criteria. The contract and/or non-disclosure agreement (NDA) may contain privacy and confidentiality elements.

In the end, you’ll need to decide if the compensating controls in these areas result in a residual risk level within your risk appetite. If not, you may be better of waiting until the SOC 2 is released.

01 May 2018

Hot Topics The Safe Systems Compliance Team 0 comment

FFIEC Issues Joint Statement on Cyber Insurance

The statement is here, and is intended to provide additional awareness about the possible use of cyber insurance to off-set financial losses resulting from cyber incidents. Here are a few high-level observations:

First of all, we’ve seen several announcements from various organizations stating that “the FFIEC has released new guidance…”. The statement makes it clear in the second sentence that “This statement does not contain any new regulatory expectations.” The statement goes on to reference the existing Information Technology (IT) Examination Handbook booklets for specific regulatory expectations. Again, this statement does not change existing regulatory expectations.
Second, this is a joint statement from all members, so we don’t expect any of the individual regulatory bodies to issue separate guidance. This is good, as we will not have to deal with any interpretation deviations. In fact, the FDIC just issued FIL-16-2018, which just links directly to the FFIEC page.
Third, the statement makes the same point we’ve already learned from the Incident Response Tests we facilitate with our customers; cyber insurance coverage is all over the map right now (or as the statement points out, “Many aspects of the cyber insurance marketplace…continue to evolve”). In other words, “Buyer Beware”*.

So how does this statement change your current approach to managing cyber risk? Probably not much. The 2015 FFIEC Management Handbook already provides guidance on the general use of insurance policies as a part of your risk mitigation strategy. Regarding cyber, they state that “These policies generally exclude, or may not include, liability for all areas of IT operations and cybersecurity.” Again, that has been our experience as we’ve conducted cyber incident response testing for FI’s, and you can try this for yourself next time you test. Whatever scenario you simulate; whether it’s malware, or customer account takeover, or a third-party breach, bring cyber insurance into the discussion. If you have (or think you have) cyber coverage, check with your agent to see if it would cover the estimated costs of the incident you’re simulating. If you don’t currently have coverage, this is a good opportunity to decide if it’s justified by evaluating costs vs. coverage limitations and exclusions using a real-life scenario.

In summary, if you already have cyber insurance coverage, the statement really doesn’t change anything. Just make sure it will be there for you if and when you need it. If you don’t currently have cyber insurance, the statement makes it clear that it’s not a requirement, but you should make sure any future consideration utilizes the framework they provide for weighing the benefits and costs.

One final thought…risk management is all about reducing risk to acceptable levels, and insurance should be the last control considered. As the Management Handbook states, “Insurance complements, but does not replace, an effective system of controls.” In our opinion, it’s a last resort, and utilized only if avoidance and mitigation efforts aren’t sufficient.

*UPDATE – Warren Buffett of Berkshire Hathaway Inc. recently confirmed this, stating “I don’t think we or anybody else really knows what they’re doing when writing cyber insurance. We don’t want to be a pioneer on this… Anyone who claims to know the base case or worst case for losses is kidding themselves”.

15 Mar 2018

Going beyond the FFIEC Cybersecurity Assessment Tool (CAT)

Hot Topics The Safe Systems Compliance Team 0 comment

Cybersecurity – Beyond the Assessment

The FFIEC Cybersecurity Assessment Tool has been out since 2015, and by now almost all financial institutions have completed it at least once, some as many as 3-4 times. Although most of the examiner feedback we’ve gotten indicates that simply completing is all regulators are looking for at this time, the FFIEC made it clear that competing the assessment is only the first step. It is designed to be a means to an end, not the end itself. The goal of the assessment process is a plan consisting of specific actions the institution can, and ultimately must, take to strengthen their cybersecurity posture. Fortunately, the tool provides those specific actions, called declarative statements. Unfortunately, there are a total of 497 declarative statements spread among 5 domains:

5 Domains of the CAT

So selecting the right domain (or domains) is the first challenge, followed by somehow drilling down to the exact statements that have the greatest impact.

The 5 Cybersecurity Steps

To best approach this challenge, let’s take a step back and re-visit the guidance. The FFIEC specifies 5 steps in the cybersecurity process:

Assess maturity and inherent risk
Identify gaps in alignment
Determine desired state of maturity
Implement plans to attain and sustain maturity
Reevaluate

If all you are doing is skipping from step 1 to step 5 (i.e. just reassessing each year), you are missing the point of the exercise. Step 4 (the action plan) is actually the goal, but to get there you must add a missing step to the process, we’ll call it step 1a:

Assess maturity and inherent risk
a. Interpret and analyze results
Identify gaps in alignment
Determine desired state of maturity
Implement plans to attain and sustain maturity
Reevaluate

According to the FFIEC, interpreting and analyzing assessment results means that management should review the institution’s inherent risks and the control maturity “…for each domain to understand whether they are aligned.” Here is where the initial challenge begins for most institutions, because the assessment tool does not provide any direct correlation between individual risks and specific controls, or even risks and domains. This critical process is left to the assessor (you). Certainly some controls and control groups are more effective against certain risks, but there really isn’t a one-to-one relationship between risks and controls. In fact, in a layered security approach to risk management it’s really a one-to-many relationship; one risk requires multiple controls. What we suggest is that you try to identify the common denominators between high risk areas, and then focus on the domain or domains that contain those common denominators.

For example, let’s say your risks are mostly least or minimal, with a few moderate. (This is what we generally see with community FI’s.) Further, let’s say that after you interpret and analyze the results, one of the common denominators with the higher (moderate) risk items is that they all rely on third-party relationships (again, very common with community FI’s). In this example, identifying declarative statements in Domain 4 – External Dependency Management would be most appropriate. But how do you get from the domain level all the way down to the declarative statement level? Here is the next challenge, because in order to identify specific controls you have to drill down into the domain to get to specific declarative statements.

Continuing with our example, since we’ve decided that additional controls in domain 4 would be most effective, let’s take a deeper dive. Here is how Domain 4 breaks down:

Domain 4 of the CAT

Let’s further assume that of the 2 Assessment Factors, the Relationship Management section is more relevant to us than Connections, since we have a pretty good idea of who we connect to and how we connect (a data flow diagram is the key to documenting information flow to external parties). Under that section, there are a total of 35 declarative statements distributed among three Contributing Components, which can be loosely described as pre-contract (Due Diligence), legal (Contract), and Ongoing. While all three are important, let’s say that since we already have a contractual relationship with the vendor(s), we’ve decided that ongoing monitoring should be our focus for increasing control maturity. Now we are down to only 11 declarative statements, and all we do from here is simply work our way up from Baseline (containing 3 statements) which is the minimum required level, through Evolving (4 statements), and into Intermediate (2 statements). According to the FFIEC, intermediate level controls are more than adequate to off-set moderate and even significant risk levels, so it’s unlikely you’ll have to progress beyond that.

In Summary

To summarize, in order to “implement a plan to attain and sustain maturity”, you must:

Analyze the results of your assessment
Find the common denominators among your increased risk areas
Identify the domain or domains most effective against those common denominators
Select the most relevant Assessment Factor(s) within those domains
Select the most appropriate Contributing Component(s) within the Assessment Factors
Identify specific Declarative Statements from among the 5 Maturity Levels, starting at Baseline and working up

The statements identified become your “plan to attain and sustain,” once they are assigned to a responsible party or group, and followed to completion. Next time you reassess, you’ll be able to check a few more statements, demonstrating your commitment to increasing your cybersecurity maturity level. And a steady increase is what you’ll need to keep pace with the increasing cyber threat environment.

← Previous 1…456 Next →