Thank you, Target! It's a pity that security managers have to capitalize on other organizations' misfortunes to broker change within their own enterprises, but the notorious Target breach of late last year just might get me some things I think my company has needed.
At issue: Gaps in the vendor management program could leave the company vulnerable.
Action plan: Use Target as an example to procure real change.
The breach may have occurred due to a gap in Target's vendor management program. Although the incident is still under investigation, it is suspected that an outside service provider that managed some of Target's heating and ventilation systems fell victim to a phishing attack that let the hackers gain access to Target's internal infrastructure and exploit resources containing customer data. I feel for Target, but this was the perfect scenario to accelerate action on findings that revealed shortcomings in the security of our company's vendor management program.
Last year, my security department approved more than 600 tickets for what we call "Vendor/Partner/Distributor," or VPD, requests. Typically, a VPD is a company or person who performs work based upon a statement of work. Since we don't have any fancy onboarding automation tools, managers simply use an online form to request access for a VPD.
Such requests trigger several email workflows. An email is sent to our procurement team to ensure that the vendor is valid and authorized to do work for our company and that the proper services and nondisclosure agreements are in place. Another email comes to my team, and we review the access request from a security perspective. A third email asks the help desk to provision an Active Directory account, an email address if needed, and an RSA software token for two-factor authentication to our partner VPN portal. Finally, the network team receives an email asking to add the user to one of our defined VPN profiles, which are configured to restrict general access to various applications.
About six months ago, we identified several weaknesses in this process. In some cases, vendors that no longer needed access still had valid accounts in our Active Directory server because the manager forgot to terminate the vendor's access at the end of a contract. To address this, we will create an automated process for terminating a vendor's access after a set period of time unless the manager requests an extension.
Another problem was that the network team too often failed to restrict access to the lowest level of privileges needed. For example, a vendor hired to modify some marketing material should have been granted access to a single document contained within a Microsoft SharePoint site, but its VPN profile let it access SharePoint, our financial servers, our HR systems and our source code repositories.
Both of those issues need to be addressed, but what really concerns me is that vendors have been allowed to download the VPN client and use it to connect to our network. Vendors are supposed to be restricted to a clientless VPN portal with links to needed applications. That keeps vendors' PCs off our network -- PCs whose integrity we can't vouch for. But any PC using the VPN client is configured as a node on our network, just as if it were plugged into an Ethernet port in our office. That, of course, ups the chances that hackers can propagate malware or take advantage of an exploit and gain unauthorized access to our network.
To mitigate this issue, I've been pushing for the deployment of machine certificates to all company-owned PCs. No certificate, no remote access to our network.
There is some work to be done to tighten this process, but now, thanks to Target's pain, I have the perfect war story to gain traction for my plans.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.