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.
Lateral Movement: Using the valid user credentials and a solid beachhead (i.e., a foothold within the target network), they now could leverage much of their research into what type of systems the target had running internally to the attacker's advantage. Along with their tools for hacking, knowing that they had SCCM and Microsoft's DNS, among other products, would have given them an advantage in looking for vulnerabilities to exploit. In addition, attackers likely would have deployed common network scanning tools to create a map to help them decide the next best steps for the lateral movement.
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.
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