From Palo Alto CEO: Beware the Internet of Things – and watch your car:

Meanwhile, corporate network security is already facing stiff challenges that have many experts saying that breaches are inevitable – something [Palo Alto Networks CEO Mark] McLaughlin isn’t willing to concede.

“It’s as if you and I would go home tonight and say to our families, ‘Somebody is going to break into the house, probably every night. They’re going to walk around, they may take stuff, take whatever they want, but they’re coming in any time they want to every day of the week, and there’s really nothing we can do about that, so we just have to be OK with that,’” he says. “Nobody’s OK with that. That’s sort of the equivalent.”

We can argue whether or not breaches are inevitable all day long. The real question is: when a breach happens, will you be ready?

People who espouse the “assume breach” mindset aren’t saying to be OK with it. What they’re saying is to make sure critical assets are protected and that when a breach occurs, the means are present to be alerted to it and contain it.

The reality is, many organizations aren’t adequately prepared for a breach and may not even know they’ve been breached.

What I regularly see in my customer engagements are flat networks beyond the perimeter and DMZ segments with no security controls in place between internal segments. The reflects the mindset that security devices will block 100% of all attacks, not letting anything malicious slip through. Which is a bit optimistic, and does not account for attacks that might not even go through the gateway.

In an “assume breach” mindset, you would design your network a bit differently, isolating user workstations from servers hosting critical applications with an enforcement point in the middle applying a strict access policy. The application servers themselves might be further segmented behind enforcement points of their own to make sure applications don’t unnecessarily talk to one another. The end user machines themselves would also have additional controls on them to provide protection when they are off network (as is often the case with laptops) and to protect data. All of this would be centrally managed all with appropriate logging, reporting, and alerting across the security infrastructure.

With all the enforcement points in place with a well designed policy, breaches, if they ever happen, can be spotted and contained quickly. With the addition of other security controls, further granularity of access control can be achieved.

If you don’t even know what your critical assets are, who should have access to them, have the ability to apply any sort of access policy, and report on activities (allowed or otherwise), you’ve got far bigger issues than any single security tool can solve.

While it’s not always a focus area of my PhoneBoy Speaks podcast, I do occasionally cover Information Security topics on my podcast. It happens often enough that I decided to create a dedicated RSS feed just for these topics: https://phoneboy.com/ps/infosec.xml

If you subscribe to the regular PhoneBoy Speaks feed, you don’t need to subscribe to this one as this is merely a subset of the episodes that appear on my regular feed. This is only for people who are interested only in the Information Security topics I cover and not some of the other stuff I prattle on about.

I know a few articles have been written about this topic already elsewhere. That said, I sometimes will do a blog post so if I need to find something again, I know it will exist on my own blog.

For a while I had been using WhiteHat Aviator, which is a fork of Google Chrome that has many privacy options enabled by default. Since, at the time of this writing, it is currently five major versions behind mainline Chrome, it’s gone Open Source, and there doesn’t appear to be any recent checkins on the GitHub project, and there will likely be some difficulty updating the existing browser, I’m guessing we probably won’t see an update unless someone undertakes a major effort.

With that in mind, I’m looking to try and configure Google Chrome as securely as possible. There is the Google Chrome Privacy Whitepaper and another independently maintained page on Privacy and Security Settings in Chrome. You could also use something like the Disconnect Search plugin. However, none of these pages solve one feature I really enjoyed about Aviator: starting up the browser in Incognito Mode. This does two important things:

  • Doesn’t log website browsing history at all

  • Clears all cookies on browser exit

However, Google Chrome does not offer an easy way to do this, but it can be done in two specific places: The shortcut you use to start Google Chrome on your Windows machine and the Windows registry. 

First, the shortcut. Find it on your computer, right-click on it and select Properties from the pulldown menu. Add a –incognito to the end of the Target field (note, it’s a space, two dashes, then incognito) and click Apply.

This will cause Chrome to start in Incognito Mode when launched from the shortcut. However, this will not cause web links you click on in other apps to also launch into the Incognito Mode. To do that, you need to edit the registry as follows:

  • Open Regedit (From the Start Menu, type regedit)

  • Find the following registry key: HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command

  • Edit the registry string (double click on “(Default)”), adding a –incognito to the value data between the quote and the double hyphen and click Ok.

Congratulations, you’re now permanently incognito in Chrome. Note if you want to use some of your extensions in Chrome, you will need to manually enable them for Incognito Mode by clicking on the hamburger menu in the upper right corner of the browser window (the three vertical lines), selecting Settings, and then clicking on Extensions. Check the “Allow in Incognito” checkbox for each one.

While it’s all fine and good that I can configure this stuff by default, I really wish Google had a one-click option that just enabled all this stuff by default.

To do something similar on the Mac, try the Google Chrome Incognito app. For Linux, it will likely be a distribution specific answer, but this should work for recent versions of Ubuntu.

I was listening to Episode 395 of the Security Weekly podcast when I heard one of the guys say that Information Security is often The Department of No. As in, no, you can't use that device. No, you can't use this new technology. Why? Because we can't secure it or control it. Because the risk of data loss is too great. Because NSA. Or whatever boogeyman The Department of No can come up with.

There are points on both sides of this debate. Anytime a new device connects to a network, regardless of what it is, there is always additional risk. If that device is controlled by the company, the risk is significantly less. If they don't control it, and there are inadequate security measures built into the network they connect to, it's another potential member of a botnet or worse. 

Despite all these risks, people want to use whatever device they want wherever they want and still get to and work with corporate data. Most users have zero clue about the potential information security implications of this, and even those that do--often those folks who sign paychecks--don't care because they want what they want, implications be damned.

So what's a poor information security professional to do? How can they become The Department of Yes while minimizing the associated risks these new technologies present?

First, we should ask the question: what is it we're trying to protect, anyway? Certainly an unmanaged devices presents a risk and should be connected to an untrusted network, such as a guest WLAN. You have your network properly segmented to allow this, right?

Next, you should ask the question: what is it that device needs access to? Certainly not the entire internal network, but some subset of it. Common items include Email, some intranet sites, their home fileshare, and maybe Salesforce. 

Of course, the minute you provide access to that data to an unmanaged device, there's a risk for that data to be lost somehow, which should raise the hackles of any information security professional. The common reactions to this phenomenon are to not allow access to any data, only allow access to very limited, harmless data, or to allow it only on condition of managing the device (i.e. with a Mobile Device Management solution). Users, on whole, like none of these options.

Another option is available, and that's the concept of a secure container. This allows an unmanaged device to access sensitive data within a container that is secured and controlled by the business. The user can do what they need to do, the data only stays inside that container, that data is stored securely on the device, and the business can revoke access to that data at any time without managing the entire device. 

The challenge with any container-type solution, of course, is doing this without compromising the end user experience. The users still need to be able to access and potentially manipulate this data in an intuitive manner. If adding a container-type solution degrades the end user experience, end users won't accept it and will demand a less secure solution. 

There are a number of different solutions that operate on this principle. The ones I am most familiar with are the ones Check Point sells. Given I work there, that should be no shock to any of you. They include:

  • Mobile Access Blade, which provides a way for unmanaged desktop/laptop systems to access corporate and manipulate documents within a Secure Workspace. This workspace is encrypted and disappears from the local system when the end user disconnects from the gateway.
  • Capsule, which enables similar access on mobile devices, as well as provides a clean pipe to mobile and desktop systems that are off your corporate premises by routing traffic to Check Point's cloud where traffic is inspected using Check Point's Software Blades using the same policy you've already defined for your enterprise environment.

Regardless of whose solutions you choose, they allow you to be The Department of Yes. Yes, you can access that data with your chosen device without the enterprise losing control of the data. Everyone wins.

While I don't typically read End User License Agreements, I was pointed to the following phrase that exists in the End User License Agreement for Palo Alto Networks equipment:

1.3 License Restrictions: End user shall maintain Products in strict confidence and shall not: [...] (d) disclose, publish or otherwise make publicly available any benchmark, performance or comparison tests that End User runs (or has run on its behalf by a third party) on the Products;

I trust you can think through the implications of this restriction on your own. It certainly adds additional color to the recent public spat between NSS and Palo Alto Networks.