The Security Impediment

From Chip Cards Take So Long, Some Retailers Disabled Them For The Holidays:

It could be that, among other things, retailers are reacting to shoppers’ sentiments. One in five consumers names transaction time as their biggest concern when using an EMV-enabled credit or debit card, according to a recent survey by point-of-sale firm Harbortouch.

It takes about seven to 10 seconds to process a chip card at the register versus two to three seconds to process a swipe. “While seemingly small, during busy times like the holidays, these increased processing times could add up quickly,” Jared Isaacman, founder and CEO of HarborTouch, said in the press release.

This is not a hypothetical problem that’s pointed out here. In a super-busy store, slowing down the entire point-of-sale system for added security can mean less customers go through the checkout, meaning the retailers make less money.

The problem is even more acute in stock trading. Delays of even a fraction of a second in receiving a trade order can cost serious money.

Organizations of all kinds often make a tradeoff between transaction speed and ensuring that transaction is authorized and legitimate. They usually err on the side of speed versus secure.

There is no right or wrong answer, because part of security is accepting risk for specific behavior that is less secure. This can happen because:

  • The cost to mitigate the risk is too high
  • The cost of failure of a mitigating security control is exceptionally high
  • The likelihood of occurence of the relevant events are very low

Security measures are often viewed–rightfully so, in some cases–as impeding business. Of course, they also enable business as well. I doubt e-Commerce would have flourished the way it did had Netscape not invented Secure Sockets Layer.

Those of us in the security industry need to ensure the solutions we are offering are not impeding business while providing a high level of security and reliability. That way, organizations won’t have to accept as much risk as they do today.

Palo Alto Networks Is Evading The Truth

Here’s a summary from A Letter to Palo Alto Networks Employees and Customers:

  • Vulnerabilities in several intrusion detection products were reported by The SANS Institute 3 years ago in a white paper called Beating the IPS, including those sold by Palo Alto Networks.
  • A few weeks ago, NetSecVulns published a video showing Palo Alto Networks gateways are still susceptible to these flaws. (Note: This video is now private)
  • Rather than acknowledge the issue, Palo Alto Networks had their representatives send out emails to their customers claiming Check Point was cheating and misleading about the issue.
  • After providing a test bed demonstrating the vulnerability in action to Palo Alto Networks, a representative finally acknowledged the issue and promised to develop a fix.
  • Claims from Palo Alto Networks representatives that Check Point is cheating and misleading about the issue continue, despite receiving concrete proof to the contrary.

The issue is a little more nuanced than this of course, so I recommend reading the piece by Moti Sagey on LinkedIn. That said, I have a couple questions of my own:

  1. Previously unknown long-time vulnerabilities such as those recently discovered in some of Juniper’s legacy products are one thing. How can a company sit on widely reported security issues for three years and not do anything to fix them or even publicly acknowledge them? We can argue about the length of time that is acceptable per responsible disclosure guidelines, or whether the issue was responsibly disclosed in this case. I’ve yet to find any information security professional who thinks three years is reasonable, particularly when the issues are this widely known.
  2. How can a company require so many manual steps to configure their security gateways to be resilient against evasions? Imagine having to perform these steps on firewalls across your enterprise, not to mention tracking continued compliance with these best practices.
  3. If this hasn’t been an issue all along, how come there is no public statement from Palo Alto Networks like there was for the Firestorm issue? Which is, by the way, still a potential issue, but PAN at least responded saying they don’t believe it is.
  4. If you received—or worse, had to deliver—the communication from Palo Alto Networks about this Evader issue that has been proven false, how does that make you feel about Palo Alto Networks as an organization?

Disclaimer: I don’t know what Check Point’s formal stance on this issue is, I didn’t ask. These are my own thoughts.

The Start of my Information Security Career 20 Years Ago

Update: For those who like to listen to audio instead of read, I recorded a version of this story in podcast form.

I’m feeling a bit nostalgic recently as I realized it’s been 20 years since I entered what we now call the Information Security industry. In the early to mid 1990s, I don’t necessarily know if this term existed, but viewing it through a current lens, I think it’s safe to say that’s when I entered.

Of course, if you count the couple of years of system administration I did while I was in college, I started sooner. Back then there was just the guys who ran the servers. They had to do it all, including security. Of course, in those days, particularly in academia, everything was wide open to the Internet. Then again, no one outside of academia and a few large companies even had Internet access and most people didn’t even know about it.

Regardless, in the fall of 1995, I was beginning my post-college career doing what I spent a couple years doing in college: administering various Unix and Windows systems. The company I worked for had in-house contractors they hired out to other firms. They also matched job candidates with jobs (i.e. recruiters). They eventually contracted me out as well.

My first exposure to proper hacking came in the form of a packet captures another engineer at this company had captured of a system break-in in progress and had managed to render in a way that replayed the session as if you were watching over the hacker’s shoulder while they were breaking into the system. Our company had a booth at the USENIX Conference in Monterey, CA and had intended to have it play in the background. As I was working the booth that day, and I was bored or inspired, I decided to narrate this break-in. It got a reasonable amount of attention.

I’ll be honest, I’m not sure where in this process I was exposed to a network firewall. It’s been 20 years and I don’t remember the exact chronology. The one thing I do know is that the first firewall I spent any serious time with was TIS Gauntlet.

The funny thing about Gauntlet, back in those days, was that even though it was a commercial product, you had to compile it yourself to install it. The logic behind this was sound: you should know the code that is protecting you. That said, even back in those days, the code that made up the handful of proxies that made up the TIS Gauntlet product was pretty complex. However, it made for some interesting installation failures. Also, the thought of having a compiler on your firewall probably made some people squeamish.

I also played with some other products: FWTK (or TIS Toolkit) in my home, DEC SEAL, and even ACLs on a Cisco router. But it was a fateful conversation from my boss at that time that ended up sending me towards Check Point FireWall-1: “how would you like to do tech support?”

At that point, I had no desire to do tech support. Even back then, tech support had a bad rap. Then again, as a sysadmin in a small company, I was often doing in-person tech support anyway. I decided to give it a try, even though I wasn’t sure I’d like it.

The company he sent me to contract: Qualix Group. There were two products I had to support there: Qualix HA, a server product that allowed you to run an application across multiple servers in a “highly available” fashion, and Check Point FireWall-1, which could also be used with Qualix HA. (Check Point did not have ClusterXL back in those days)

I ended up loving it, and the rest is history. I ended up doing it for more than a dozen years for three different companies, learning quite a bit about Check Point FireWall-1 and Information Security in the process. I’m glad I’m not doing that job today, but it was a great stepping stone to where I am today.

The bottom line: Don’t be afraid to try something new and outside your comfort zone. This attitude has always served me well, not only in the very beginning of my career, but throughout. No matter how it turns out, you learn something in the process that will help you take the next step in whatever direction you want to go.

Another important point: if you want to get a start in information security, work on a helpdesk or in a technical assistance center. The amount of basic, practical knowledge you’ll pick up is substantial and will help you decide exactly where in the industry where you want to focus your career.

For various reasons I decided to move the hosting of this blog to Github Pages. This also meant changing the backend to Jekyll, which I already use for phoneboy.com anyway, but I use a different hosting arrangement there. I now have a nice, spiffy new site theme as well. Not that too many people care about that stuff.

I’ve also realize in the various moves the RSS feed changed a couple of times. For those of you still using RSS feeds, it’s now: http://phoneboy.org/index.xml

From Palo Alto Networks: Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions:

To monitor and protect your network from most Layer 4 and Layer 7 attacks, here are a few recommendations

While I’m all about Best Practices documentation, one wonders why some of the items in this documentation are even required.

Block all unknown applications/traffic using security policy. Typically, the only applications that are classified as unknown traffic are internal or custom applications on your network, or potential threats.

Wouldn’t a better approach be to only permit the applications you want to allow rather than to block all unknown applications? Oh, wait, that’s not how that product was designed to work…

Create a zone protection profile that is configured to protect against packet-based attacks: * Remove TCP timestamps on SYN packets before the firewall forwards the packet […] * Drop malformed packets. * Drop mismatched and overlapping TCP segments

A proper stateful firewall should do all of these things by default, shouldn’t it? Same with the half dozen other checks they say to enable via the CLI?

Doesn’t it seem strange to anyone else that you have to manually configure so many options to make the device more secure? What’s the likelihood customers have actually deployed their gateways in this fashion? Are they getting the performance they expect if they do so? My guess: probably not.

To add a little more fuel to the fire: Firestorm. This attack uses TCP SYN + Data packets to bypass certain firewalls. Per the article:

We disclosed the full details of the vulnerability to major vendors affected by the flaw. One of the vendors who replied, explained that they do not see this issue as a vulnerability because, by design, their firewall permits full TCP handshake in order to inspect the application type.

They said that once their state machine proceeded beyond the TCP handshake, they would recognize the application, matching a subsequent rule that applied to application traffic. The vendor added that if there was an application they did not recognize, they would treat the session as ‘unknown-TCP’ and, again, perform an additional security policy lookup to decide whether to allow or block the traffic.

Now that this information is out there, it is only a matter of time before some develops a tool that can be used to bypass these security devices and, short of blocking all traffic, there’s nothing you can do to mitigate the threat “by design.” Oh wait, someone already has. (Note: There was a tool at https://github.com/stasvolf/SynTunnel but it has been removed)

It should be noted that Check Point Security Gateways are not susceptible to Firestorm.

Disclaimer: While I work for Check Point Software (a competitor to Palo Alto Networks), the above thoughts are my own.