From Cybercrime poses a potential existential threat to our society, and we’re completely unprepared:

Connecting our cars and pacemakers and planes and power grids to computers gives us access to computing power that was unimaginable decades ago.

But it also means that we have security threats that were unimaginable decades ago, which Goodman says is a potential existential threat to society, the sort of thing that needs to be a national priority as big as the space race or the Manhattan project.

The premise of this article is that the lack of cybersecurity around critical infrastructure and the increased prevalence of cybercrime poses an existential threat to society. Existential meaning “of or relating to existence.”

It’s a pretty bold statement. It’s also, based on the cross-section of companies and security experts I’ve talked to, a very real possibility.

Where I disagree with the article is the fact that we need some sort of Manhattan Project-type effort to solve the problem. As if developing a single nuclear-type weapon will be enough to prevent all cybercrime.

Those of us who’ve been in the industry for a couple of decades already know how to significantly reduce the risks. It doesn’t even require new technology, though some organizations will undoubtedly need to acquire some.

The one thing that it will surely require from all organizations and all persons is applied effort. And sadly, the only way I see the majority committing to that is for a nuclear-type event to occur. Only, it will be much more harmful than Trinity was.

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.

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.

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