I was recently interviewed for an article explaining what CTI is. The article is published, but I think my full answers provide a little bit better context. You can read the article here. If you want the full, unpublished answers I gave, check it out on my corporate blog.
Thursday, March 23, 2017
Thursday, March 16, 2017
TicketBleed - making the case for packet capture
You may have heard about the TicketBleed vulnerability that plagued some F5 devices. Though it's been a while, I figured it would be worth the time to put out this case study on why it makes the case for packet capture at strategic locations.
I personally don't think a bug impacting so few devices (it requires a non-default configuration) is worthy of naming, but hey to each their own. If you are an F5 customer, you certainly care about the bug and I don't blame you a bit. Otherwise, meh.
But I think the #TicketBleed vulnerability is a good example of why you need full network traffic capture. I covered the HeartBleed vulnerability pretty extensively for SANS and dealt with the fallout in customer environments. One of the questions people asked me consistently was "how can I tell if I've been exploited?" Unfortunately, successful exploitation would not create any logs. Netflow is also useless for detecting HeartBleed exploitation. The same is likely true for TicketBleed.
But with packet capture, HeartBleed (and now TicketBleed) can be detected. But where should your taps for packet capture be located? Most would say after traffic is decrypted (e.g. after a VPN concentrator). I would normally agree with this advice, but vulnerabilities like TicketBleed and HeartBleed show that this isn't always the right answer. There are exceptions to every rule. In order to execute the discovery Course of Action (CoA), you need some amount of packet capture.
Any time a serious vulnerability is discovered, there is always a question about whether you may have been exploited before you were patched. This is especially concerning for those who have nation states as part of their threat model. If you haven't considered a packet capture or other network security monitoring, please talk to us at Rendition Infosec and we'll be happy to help you plan for success in your next investigation.
I personally don't think a bug impacting so few devices (it requires a non-default configuration) is worthy of naming, but hey to each their own. If you are an F5 customer, you certainly care about the bug and I don't blame you a bit. Otherwise, meh.
But I think the #TicketBleed vulnerability is a good example of why you need full network traffic capture. I covered the HeartBleed vulnerability pretty extensively for SANS and dealt with the fallout in customer environments. One of the questions people asked me consistently was "how can I tell if I've been exploited?" Unfortunately, successful exploitation would not create any logs. Netflow is also useless for detecting HeartBleed exploitation. The same is likely true for TicketBleed.
But with packet capture, HeartBleed (and now TicketBleed) can be detected. But where should your taps for packet capture be located? Most would say after traffic is decrypted (e.g. after a VPN concentrator). I would normally agree with this advice, but vulnerabilities like TicketBleed and HeartBleed show that this isn't always the right answer. There are exceptions to every rule. In order to execute the discovery Course of Action (CoA), you need some amount of packet capture.
Any time a serious vulnerability is discovered, there is always a question about whether you may have been exploited before you were patched. This is especially concerning for those who have nation states as part of their threat model. If you haven't considered a packet capture or other network security monitoring, please talk to us at Rendition Infosec and we'll be happy to help you plan for success in your next investigation.
Subscribe to:
Posts (Atom)