From Living On An Exponential Curve Of Breaches:

The knowledge that a major networking gear manufacturer’s product has been compromised will raise the question: just how does one trust that products one has purchased are not compromised by a government or sophisticated hacker? Are vendors prepared to submit their products to 3rd party testing labs for assurance purposes? At the very least that assurance should come from complete code reviews and broad spectrum fuzzing. This is an expensive proposition, one that will have to be incorporated in every vendor’s release schedules. At the end of the day will that level of assurance be enough?

Of course, we’re talking about the recent Juniper and Fortinet vulnerabilities that allow unauthorized administration access, and of course made the news.

I don’t know that you’ll get any security company to submit their source code to an external third party code review, but third party validation and assurance testing seems perfectly reasonable. In fact, vendors already do this with NSS Labs and Common Criteria testing.

Meanwhile, you have vendors with restrictive EULAs that forbid this kind of activity. Which, given that this particular vendor spends more than half of their revenue on marketing, makes you wonder if they’re in the security business or the marketing business.

A marketing message came across my LinkedIn feed, which is starting to look a lot like my Facebook feed. It was about Anti-Virus and how a particular vendor’s product uses less memory than competing products. Nothing about efficacy. Of course, in a highly commoditized market, one would assume (rightly or wrongly) that the efficacy of all products in the space are similar.

Of course, even if you speak to efficacy, it’s largely a statement about how the product did in a specific test and, like the oft-repeated financial services disclaimer “past performance is not indicative of future results.”

This kind of marketing misses the mark. It’s marketing to technical people about things only technical people would care about. The people who make the decisions to purchase said products aren’t always technical. Sadly, I see it all too often from all corners of the information security space.

The Jobs To Be Done Framework

I was first introduced to this framework as a result of listening to The Critical Path, a podcast “contemplating the causality of success and failure in the evolving story of mobile computing and related industries.” Host Horace Deidu actually uses this framework quite a bit in the analysis he does on the podcast. The framework comes from Harvard professor Clayton Christensen and was developed as a way to look at customer needs by focusing on their fundamental motivation. Or, as the Innovators Toolkit says, highlight the human need you’re trying to fulfill.

To summarize the framework very briefly, people buy goods and services are bought because they perform certain jobs. These jobs can be sorted into main jobs and secondary jobs (usually in conjunction with a main job). These jobs have both functional and emotional aspects to them. People take all of these things into account when deciding which product or service they will “hire” to do these jobs. A more detailed explanation of the framework is available on the Innovators Tooklit site.

To bring this into context of the current discussion: companies don’t buy information security products or even hire information security professionals “just because”–there’s an underlying motivation to do so. A “job to be done,” if you will.

What Are The Jobs To Be Done?

Every organization has its own reason for existing, a job for which it hired to perform for someone else. In turn, they hire individuals, products, and services to do specific jobs to support that main task.

Why are information security professionals hired? Generally because the organization feels they have information assets that require protecting. In many organizations, people who originally served a different purpose are now tasked with protecting information. This can be a bit like using a screwdriver to drive in a nail. Sure, you might be able to actually use it for that in some circumstances, but it’s not the right tool for the job. Unlike a fixed object like a screwdrivers, people can actually evolve their skills and talents becoming the right tool for the job.

What are the jobs to be done in information security? Quite a lot, actually, but they mostly boil down to protecting the confidentiality, integrity, and availability of information assets. This is known as the CIA Triad (not to be confused with the Central Intelligence Agency in the US Government).

Confidentiality, integrity, and availability are meant to be taken in equal measure. When it’s not possible to ensure all three equally, I often see organizations err on the side of availability over the other two elements, which often leads to the DAD Triad: disclosure, alteration, and destruction.

Back To Marketing: Speaking To The Jobs To Be Done

In looking at some of Check Point’s competitors in the space, I see words like detection, protection, or even “take decisive action.” Are these the jobs you want done with respect to your information assets, or would you like something stronger?

Check Point uses much stronger language: prevention, as in Next Generation Threat Prevention. Or if you’re talking about the SandBlast sandboxing product for zero-day malware, another term that is used: threat extraction (as in extracting the threats from documents). In other words, Check Point’s products prevent threats from reaching your information assets.

Palo Alto Networks, to their credit, also uses the word prevention, and it’s definitely a better “job to be done.” Perhaps that’s why both Check Point and Palo Alto appear as “leaders” in the most recent Gartner’s Magic Quadrant for Enterprise Network Firewalls.

Actually Performing The Job To Be Done

One thing to note about Gartner is they measure perception. Reality is measured by another organization: NSS Labs. They do this through a series of group tests performed on various security products and provide the results to paying customers. Vendors such as Check Point can also purchase marketing rights to the reports as well. If you’re interested, you can see how Check Point performed in the latest Breach Detection Systems test. The TL;DR version: a “recommended” rating was received, as Check Point has received on numerous group tests over the last several years.

One vendor is conspicuously absent in the latest BDS test: Palo Alto Networks. NSS Labs CTO Bob Walder had something to say about this:

Question:If a vendor not only refused to participate in a test,but actively blocked our purchase of their product,would you want to know?

— Bob Walder (@bwalder) February 17, 2015

Given that PAN’s EULA forbids publishing third party test results, the only way to validate any of their claims is in your own lab. Should they make your shortlist, I highly recommend testing it head-to-head with other, competitive solutions ensuring you follow PAN’s Best Practices.

From Turkish Clicker: Check Point Finds New Malware on Google Play

The Check Point research team has discovered an extensive malware campaign on the Google Play™ store. Check Point Mobile Threat Prevention detected the first samples of malware we call “Turkish Clicker” on several customer devices.

The malicious code was found in the apps “Fruit Life,” “City HD Wallpapers,” and “Adiyef Puzzle.” Google has removed all of these apps from Google Play.

Like BrainTest, which Check Point researchers discovered in September 2015, this demonstrates how easy it is for fraudsters to publish malicious apps on official app stores like Google Play.

While official App Stores such as Google Play and Apple’s App Store are no guarantee of a malware-free experience, they do a level of checking on apps submitted to ensure they are what they say on the tin and not doing something nefarious behind the scenes. Malicious app makers are engaging in a sort of cat-and-mouse game to try and sneak their apps through the review process, though once found, these malicious apps are removed from the official app stores.

Worse things can happen with unofficial applications or even ones that look official, but are sideloaded. Avoid it if you can. Meanwhile, if you have corporate data on your personal device, that data should be protected with a solution like Check Point’s Mobile Threat Prevention,

From Press Backspace 28 times to own unlucky Grub-by Linux boxes:

A pair of researchers from the University of Valencia’s Cybersecurity research group have found that if you press backspace 28 times, it’s possible to bypass authentication during boot-up on some Linux machines.

The problem’s not a kernel nor an operating system problem, but rather one in the very popular bootloader Grub2, which is used to boot an awful lot of flavours of Linux.

Essentially, if you enable Grub2’s password protection during system startup, it won’t do you much good – it can be easily defeated. (Luckily, the vast majority of distributions of Linux do not enable this by default.)

I don’t want to say this is a non-issue, because it’s not. That said, it helps to have some perspective on the impact of a potential vulnerability so you know what you should do about it at what priority.

When I worked in the TAC back when I was at Nokia, I was the guy who would decipher the latest “OMG, my scanner found your firewalls are vulnerable to this new CVE, fix it.” This meant reading the actual CVE to figure out if this could lead to remote code execution, cross-site scripting, or similar.

Because of how Nokia IPSO was hardened, many of the vulnerabilities had no particular impact, either because the vulnerable component wasn’t there or it was configured in a more secure configuration than the default.

Or, better yet, in order to leverage the exploit, you had to have a specific kind of access to the machine (say, shell access) that could lead to far more dangerous things than the vulnerability in question.

This Grub bug is one of those things. First of all, this bug only shows up in a non-default configuration and requires physical access to boot. Ok, so maybe also a serial console might work, too. Either way, this limits the potential scope of a potential attack. Furthermore, if you actually have physical access, unless you’ve performed some sort of drive encryption, that physical access could be leveraged to, say, steal or clone the drive. Which is a far more serious threat.

In the grand scheme of things, this bug would not be a huge priority to deploy a patch for in all cases. Unlike, say, the backdoor in Juniper/Netscreen gear which can be remotely exploited.

You may have noticed a marked increase in the amount of posts I’ve done to this blog lately. Or maybe you haven’t because I’m just one of many people in your Twitter, RSS, LinkedIn, Medium, or however you read and/or ignore my stuff.

Whether you read these ports or not, all these new posts aren’t necessarily an accident. There is a underlying motivation driving me to put thoughts around Information Security to digital bits once again.

What is it? A sense of purpose that, quite honestly, I haven’t felt in a while. About the Information Security industry. About where I see things happening and some things we need to do to affect positive change, creating a more “secure by default” environment for everyone and everything.

Do I think it will happen overnight? No. Do I have all the answers about how to get there? No. That said, 20 years in this industry has given me some ideas about what works and what doesn’t.

What I do know is that the bottom-up approach that many are taking to affect change isn’t working that well. By that, I mean that initiatives for Information Security are usually not coming from the people in charge, but rather the IT (Security) personnel who, innately, understand something needs to be done, but they can’t explain it to the people who write the checks in a way that will get the necessary funding required to affect change.

Sometimes, security initiatives are actually driven from above as well. Frequently, it comes after a major incident that makes the news. I bet Information Security suddenly became a lot more important at the various retailers that had millions of PCI and/or PII data records stolen. However, there’s no evidence those efforts have resulted in improved security or that other, similar organizations have started taking the necessary actions to improve their information security practices before they are the next target.

There’s a lot of platitudes and sound bytes out there about how organizations can be more secure. There’s a lot of noise from vendors in the space about their solutions and how, if you buy and deploy their stuff, they will keep you secure (and those other vendors who have competing products won’t).

This problem, and the solutions, are far more nuanced than any sound byte can capture or any single product suite can solve. It’s about bridging the gap between the technical information security people who know what’s going on and the people making the strategic decisions and writing the checks.

This is the kernel of the idea I have. The details of how to do this need a bit more refinement. When I put these ideas out there, I expect the Internet to tell me how wrong I am:

I’m not afraid of that. In fact, I welcome it. One lesson I learned from maintaining the old FireWall-1 FAQ was that when I put wrong information out there (not intentionally, of course), someone will tell me and give me the right information. Then I can share that information with others, as I’ve done for 20 years.

When the time comes, I would like to share these ideas with a much wider audience than my old FireWall-1 FAQ was able to reach. If you have any suggestions or feedback, I’d love to hear your thoughts.