Vendor Risk is a relatively new anomaly. I sometimes wonder how we ever got through the 90’s. It seems like only a few years ago when vendors received a key, code, or swipe card to come through the front door of our buildings whenever they liked. We trusted them to do their job once inside. I also wonder how, as children, we ever survived without seat belts as we bounced around in the back of our parents’ sedans. Looking back we acknowledge both examples as high security risks, the difference now being our tolerance level for those risks based on our current environment.
Today, vendors still come in the front door but they also come in through our network doors. In some small way we still assume their security protocols and checks are top-notch. What we are finding though is far from the case. If we look at several of the breaches in the recent years, the main point of entry was through the vendor network relationship.
My prior life as a network administrator
I remember the days as a network administrator, where some manager from some department handed me a sheet of paper which read “we need to open this today.” I did this hundreds of times. I can tell you with absolute certainty that each week that passed the further the importance or clarity of that configuration became. It was just a day in the life of a smoke jumping network admin. I could lie to you and say there was more science behind it, but there wasn’t. My rationalization was, “I locked the network or IP of the vendor to specific ports or areas, or when they are VPN’d, they will do the right thing”. The fact of the matter is many of the “network opening” requests consisted of very little detail of the who, what, where, or when. So in order to fulfill the demand, I simply either 1. Created the ID, slapped a default security policy, or 2. allowed the network or IP of that vendor to any port. The main reason for this sloppiness was the Vendor may have complained that “stuff” wasn’t working and they had to troubleshoot an issue.
We live in a new era that demands better security. We ask more questions, even ask for audits of the vendor network. Regulators designed compliance guides to manage activity. We’re on the right track. But the reality is there are still lots of network administrators dealing with vendor network relationships in the firewall from years past. Managing those past-down rules becomes nearly impossible.
Time goes on and organizations grow into their networks, and technical debt comes along with it. While I feel most network admins build their network relationships to mitigate as much vendor risk as possible, they continue to count on the firewall or other downstream security devices to drop what is not permitted. In a recent report from Forrester on Cybersecurity Risk, they state, “the best cyber-risk rating solutions don’t merely report on your third-party partners’ security flaws, they contextualize and prioritize the risk information they collect so you can more strategically allocate resources and mitigate risk.”
Let’s make a paradigm shift and ask a new question.
A Vendor is violating our network relationship by scanning, or attempting access to a different port, that wasn’t agreed upon. Why?
We should be able to make changes to the network on the fly when a Vendor is making low-level attempts to restricted ports and IP’s. Today most firewalls will just drop the connection, note it, and move on. These missed attempts happen at alarming rates in the sea of logging and alerting. As history shows, they can be game changers to any organization. My suggestion, review who has your current keys, monitor all your doors, and use the threat intelligence to get alerted to those that come knocking where they aren’t expected. In other words, put on your seat belts!
–For more information on how PacketViper supports Vendor Risk download this data sheet.