Cybersecurity and Third-Party Risk. Gregory C. Rasner

Чтение книги онлайн.

СКАЧАТЬ collection from all the different POS machines was then sent to a compromised server internal to Target's network. The data was then retrieved via a number of electronic “drop” locations worldwide. The Target team in India notified the Minneapolis team of the attack, but they took no action on the warning.

The breach itself took place from November 27 to December 15, 2014. Obviously, we do not know how long the research phase took for the attackers. What the timeline does show is how methodical and clever attackers can be when attempting to ambush a victim. In this case, leveraging the available public information not only got attackers access to the vendor portal, but also gave them candidates from the vendors so they could select one with lower access standards. This breach cost Target hundreds of millions of dollars in direct damage, lost revenue, and reputational costs. Many C‐level and lower‐level employees lost their jobs, including the CIO and CEO, while the board of directors was threatened with removal as well.

      Inside Look: Home Depot Breach

      Occurring in 2014, the attacker in the Home Depot breach used a third‐party's logon credentials to get into that vendor's environment. Once inside the vendor's network, they leveraged a zero‐day exploit for Windows that gained them access to Home Depot's corporate environment. Within the Home Depot network, they deployed memory‐scraping malware to the company's POS systems, resulting in over 50 million credit and debit cards numbers being stolen along with a similar number of email addresses. Valid customer email addresses are a gold mine for phishing attacks. Several studies were done on how Home Depot could have installed IDS/IPS, end‐to‐end encryption, network segmentation, and other technical and process improvements to detect the vulnerabilities exploited by the attackers. Very little is ever mentioned about how a more robust cybersecurity due diligence program would be appropriate for vendors.

      This third‐party vendor had a connection to Home Depot. While we have focused most of the discussion on data security, there are vendors who will need to connect to your network to perform their business function. These types of vendors pose risks like the Home Depot incident demonstrates: Their inadequate security controls were the beachhead the hacker needed. Legitimate cases can be made that if Home Depot had better security patterns in its enterprise, the attack might have been either prevented or caught much earlier (they lingered for months). However, if Home Depot had taken our more Cybersecurity Third‐Party Risk approach, the risk of the beachhead being established would have been reduced.

In this updated approach, we want to look at a few items:

       Did Home Depot have language in its contract with this vendor? Did it have:Appropriate cybersecurity language in the contract with the vendor who had a direct connection to the Home Depot network?Provisions in the contract language allowing Home Depot to perform validation or gain assurance of the vendor security controls?

       A few high‐level questions should have been more diligently reviewed:The hardware most vendors maintain at a customer's sites for end‐to‐end connectivity often falls into a no‐man's‐land of who maintains it. If the third party owns it, make sure they do so securely. Did they verify it on a regular basis that is pre‐established with the vendor to set expectations?What was their access management policy and how did they enforce it in production? If they had a policy, how did it not catch this activity? Was logging and monitoring insufficient?What was the vendor's patch management policy and were they aware of the zero‐day exploit available in the version of Windows?

      Notice many of these questions are incident management–type questions a cybersecurity incident management team (CIMT) would typically ask internally. In this case, it is a third‐party risk team asking similar questions of vendors, leveraging language that is written into contracts, and managing their security as an extension of your own.

      Author's Note: Applies to Any Size

While much of this book discusses firms large enough to have the size and complexity for cybersecurity teams and TPRM programs, there are ways to implement the recommendations for even one‐person firms. The book speaks often of a “risk‐based approach.” A risk‐based approach allows for any firm to customize the program based upon its needs and size. Whether you are a large, multinational, or a small business serving your local area, this Cybersecurity Third‐Party Risk program can be made to reduce your organization's risk.

      To illustrate this is possible, we can consider an example of a small one‐person organization: a sole owner of a business. This type of business typically does not have access to the cybersecurity or risk management expertise natively. A small‐business owner can first start by making an inventory of all their vendors who have their customers' data or a connection to their network (i.e., their computers). Once it's known where the company's data is located, then the owner can ask some questions about how their vendors secure the data.

If the business has more than one vendor with customer data, sort them by the highest risk. The highest risk can be based upon their number of records. Without the cybersecurity expertise, the questions and answers can be intimidating; however, there are options. Search the internet for help and answers. Explore around for a local technology business that, as a small‐business owner, you can barter support with for the more technical questions. Another option is ask the vendor for help explaining some of the more complex items.

      When performing the due diligence activities as a smaller entity, it is dealt with in a similar fashion: Design it to meet the risk. Vendors with your data, listed in risk order, allows you, a business owner, to engage and ask questions. Whether you perform just remote assessments (e.g., questionnaires sent to the vendor) or on‐site assessments (e.g., physical validation at the vendor site) or both can be determined by your risk appetite. If one or more of your vendors has a lot (or all) of your customers' data, at a minimum, ask very detailed questions on the intake (when you're first deciding if they are going to be a vendor). That is the time you have the most leverage. Once the contract is signed, you will lose much of your ability to effect any change.

      Pick a cadence for review of their security. Quarterly, yearly, bi‐annually? In risk order (i.e., high to low), send them a questionnaire about their security to confirm nothing has changed. Knowing you don't have the staff or expertise to review 100 questions, ask questions that elicit the answers you require. For example, rather than ask a technical question about encryption, ask it like this, “How is my customers' data protected?” You might get back some technical answers: however, as described earlier, there are ways to cut through some of the technical jargon by reaching out when needed.

      The principles and actions suggested in the book should be applicable regardless of the size of your firm. Tailoring it to the needs of the company depend on acceptable levels of risk and priorities.

Conclusion

Cybersecurity, like many technology‐based careers, is complex and typically takes a good deal of training, studying, and immersion in the field to become proficient. The basic cybersecurity triad of Confidentiality, Integrity and Availability can serve as guideposts for any risk discussion around data protection and third parties. Information security focuses on ensuring that data stays restricted to those authorized to access it, protected so it is not altered, and accessible to those permitted to get to access it. Cybersecurity can cover a wide spectrum of activities in most enterprise networks, and will be the basis for how due diligence and due care activities are to be performed in upcoming chapters.

      Cybersecurity frameworks provide organizations with guides to how to lower their risk to security incidents. Frameworks to focus on include NIST‐CSF, ISO 27001 and 27002, NIST‐853, Federal Information Security Management Act of 2002 (FISMA), New York Department of Financial Services (NYDFS), and any that are applicable to the industry, country, or region where business is conducted. The adoption and adherence СКАЧАТЬ