Threat Detection – How Well Do Know Your Profiles?

No alt text provided for this image

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:

  1. 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.
  2. 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 these three cases, 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.

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 excellent ways of understanding who talked to whom but wire data—the 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.

If you’re a fuel dispenser merchant, by all means, 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?

No alt text provided for this image

If this subject is of interest to you, check out this related Enterprise Security Weekly podcast.

要查看或添加评论,请登录

Ward Cobleigh的更多文章

社区洞察

其他会员也浏览了