Cybersecurity and Third-Party Risk. Gregory C. Rasner

Cybersecurity and Third-Party Risk - Gregory C. Rasner


Скачать книгу
valid credentials, no alarms were sent. This type of credential from the vendor gave them the continuous access to make repeated attempts at the next steps for the breach.

      Privilege Escalation: As attackers moved laterally within the Target environment, the objective would be to find privileges that worked with the POS system. As they exploited these known vulnerabilities on the Microsoft and other systems they had identified in their reconnaissance, intrusion, and lateral movement phases, that data was leveraged to elevate themselves to be able to perform the last step.

      Exfiltration: The malware was distributed to the POS machines in such a fashion as to suggest it was an automated update, indicating that the attackers had attained privileged access to the central system that updates those machines. Because the malware was custom written, virus scanners did not have their signature to detect it. As the payment cards were swiped, their data was stored in a system configuration file that was shared over well‐known ports. This data 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.

      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.

       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

      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.

      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


Скачать книгу