VISA Security Alert: How Well Do You Know Your Profiles?
Recently, VISA published a Security Alert that described three attacks targeting point-of-sale (POS) systems. While fuel dispenser merchants’ POS environments were the targets, this little article is not about bad guys and gas pumps, this is a discussion about profiles.
What profiles? Why profiles? In this context, let’s define two types of profiles this way:
- Host profile – a device, or group of devices, that communicate in a very predictable and often identical manner. Host profiles might be used to specify the network conversations we expect to see from POS systems, ATMs, patient monitors, IOT devices, wearables, printers, etc.
- Service profile – a capability or function that is expected to behave in a defined way. For example, all DNS responses should come from the specified DNS Servers. Or, all user Web requests at a location should go through the configured Web Proxy.
Conceptually then, the creation of profiles is like whitelisting. As specifically as possible, define the conversations that are permitted.
Why? In the three cases described by VISA, the threat actors did not access their ultimate targets directly. They first gained access to the merchant networks (via phishing email), conducted reconnaissance, obtained credentials, and moved laterally across the corporate network into the POS environment. At some point in this process, devices had to start behaving in an abnormal way. Certainly, when payment data was being exfiltrated, this should have become obvious, if not sooner.
Simply put, profiles are a way of defining expected behaviors and a way of identifying the unexpected.
At this point you may be thinking, this all sounds rather reactive. That’s true. Creating profiles is just one step in mitigating against threats. Full disclosure: the guy writing this article has spent most of his professional career working with network monitoring tools. So, when I see that one of the recommendations in the VISA report is: “Monitor the network for suspicious connections,” I immediately think of how readily available sources of monitoring data can help.
Flow data (NetFlow, IPFIX, etc.) is an excellent way of understanding and validating normal conversation patterns. Those patterns can then be translated into profiles, e.g., these source addresses normally talk on these ports to these destination addresses.
Flow can also be used to identify abnormal protocol behaviors such as “lonely” SYNs that could be indicative of a SYN attack or network or port sweep. The addresses found in flow records can be compared to blacklists, alerting you to bad actors trying to talk to your hosts or worse, telling you that one of your hosts has responded.
But there may come a day when all the proactive defensive measures fail. That’s why we have Security Alerts – someone’s plan didn’t work. What then? Flow data and profiles are still excellent ways of understanding who talked to whom but wire data—raw packets—remain and shall always be the ultimate source of forensic evidence and truth when the time comes to reconstruct the events and document the damage.
Fuel dispenser merchants, by all means, should be on guard against the bad guys at the gas pump. For the broader audience, know how your devices and your services should communicate. Take the time to document those behaviors. How well do you know your profiles?
If this subject is of interest to you, check out our Enterprise Security Weekly podcast to see a live demonstration of how the VIAVI Observer solution can aide in your security efforts. To learn more about the Observer solutions visit our website.
If you would like to see a demonstration of how Observer can work within your environment – request a demo today.