Controlling remote access tool usage in the enterprise

12. October 2011 · Comments Off on Controlling remote access tool usage in the enterprise · Categories: blog · Tags: , , ,

Palo Alto Networks’ recent advice on controlling remote access tools in the enterprise was prompted by Google releasing a remote desktop control feature for Chrome, which also has the ability to be configured “to punch through the firewall.”

As Palo Alto Networks points out, the 2011 Verizon Data Breach Report showed that the initial penetrations in over 1/3 of the 900 incidents analyzed could be tracked to remote access errors.

Here are Palo Alto Networks’ recommendations:

  1. Learn which remote access tools are in use, who is using them and why.
  2. Establish a standard list of remote access tools for those who need them
  3. Establish a list of who should be allowed to use these tools.
  4. Document the usage guidelines, complete with ramifications of misuse and educate ALL users.
  5. Enforce the usage using traffic monitoring tools or better yet, a Palo Alto Networks next-generation firewall.

 

 

Why Counting Flaws is Flawed — Krebs on Security

27. November 2010 · Comments Off on Why Counting Flaws is Flawed — Krebs on Security · Categories: blog · Tags: , ,

Why Counting Flaws is Flawed — Krebs on Security.

Krebs calls into question Bit9’s “Dirty Dozen” Top Vulnerable Application List which placed Google’s Chrome as number one. The key issue is that categorizing vulnerabilities simply by severity creates a misleading picture.

Certainly severity is an important criteria, but does not equal risk. Krebs highlights several additional factors which affect risk level:

  • Was the vulnerability discovered in-house — or was the vendor first alerted to the flaw by external researchers (or attackers)?
  • How long after being initially notified or discovering the flaw did it take each vendor to fix the problem?
  • Which products had the broadest window of vulnerability, from notification to patch?
  • How many of the vulnerabilities were exploitable using code that was publicly available at the time the vendor patched the problem?
  • How many of the vulnerabilities were being actively exploited at the time the vendor issued a patch?
  • Which vendors make use of auto-update capabilities? For those vendors that include auto-update capabilities, how long does it take “n” percentage of customers to be updated to the latest, patched version?

When taking these factors into consideration, Krebs opines that Adobe comes in first, second, and third!!