Default permit still winning the security battle

I was stoked when Patrick Gray took up my suggestion to ask Marcus Ranum to reflect on “The Six Dumbest Ideas in Computer Security“.  I encourage you to listen to the interview for yourself, but my summary of it is that Marcus was mostly discouraged that very little progress has been made in computer security, while Patrick was of the opinion that a number of good lessons had been learned in certain key areas.

Patrick pointed particularly to Apple’s iOS as a commercially-successful example of default-deny execution policy.  Whilst iOS, Windows Vista and later, and even Android (to a lesser extent) have implemented varying levels of default-deny when it comes to execution of programs, I think default-permit policy is still the dominant mindset in our industry.  As I was listening to the interview, a few areas came to mind where it still seems to be true:

  • Outbound connections from client devices.  Despite the fact that client-based exploits have become the dominant method of compromising organisations (the so-called “Advanced Persistent Threat” which compromised RSA was started with a phishing campaign and an Excel-delivered Flash exploit) and security practitioners generally assume that client devices (whether PCs or phones) are routinely compromised, many (most?) networks provide allow outbound connections from client devices by default, often to any destination and sometimes on any protocol.  This is exacerbated by the appalling lack of proxy server support in most iOS and Android applications, which means that administrators of BYOD networks rarely have any choice in the matter if they want to provide a functional service.
  • Compounding the problem is the fact that generally when users browse or client-side apps make connections, all web sites are allowed.  In this area, enumerating badness (Marcus’ stupid idea #2) is still dominant; many (most?) web filtering solutions which attempt to protect clients from malware use a blacklist of known-bad sites.
    I’ve worked in K-12 school IT management, support, and consulting for a number of years, and every now and then the suggestion of whitelisting web sites comes up.  That’s usually all that happens.  Other fields (perhaps banking, industrial control systems, or medical applications?) might also consider it, but I suspect that they end up with similar conclusions (i.e. that it’s impractical to implement).  (I’d love to hear from anyone who has actually tried this in a real network.)
  • Scripting languages are a common exception to the default-deny execution policies of operating systems.  To my knowledge, Windows PowerShell is the only common scripting system which allows for script signing policies.  However, scripts can request that Windows simply turn this feature off, which defeats the purpose.  To my knowledge, no signing system or default deny policy has ever been implemented for Unix/Linux systems (other than the default protection provided by Mandatory Access Control systems like SELinux and AppArmor).
  • The Android application permissions system is one of my pet peeves. Android applications must inform the Google Play store about which security- and privacy-related features they intend to use.  This is good; however, permissions are approved when the application is installed, and users only have the choice of installing or not installing.  Many applications require permissions that are not obviously critical to their operation, but because users typically try to install an application because they want to use it, an informed evaluation of an application’s permissions is rarely performed at installation time.  Most applications are installed regardless of what permissions they request.  So effectively, this becomes a default-permit situation.  (Moxie Marlinspike‘s WhisperSystems seemed to be making progress on this before they were acquired by Twitter, and I hope that Open WhisperSystems takes up this work again in the near future.)

All of this says to me that we’re still living very much in a default-permit world, and there’s a lot of work to be done before we can confidently say that progress has been made in this department.

I’d love to hear any further thoughts on this; you can reach me through the feedback page, or on Twitter.

Source: libertysys.com.au

Spam insights from Project Honeypot

Project Honeypot just published a report of their experience in processing 1 billion spam messages.  Highlights for the impatient:

  • For the past 5 years, spam “bots have grown at a compound annual growth rate of more than 378%. In other words, the number of bots has nearly quadrupled ever year.”
  • The top 5 countries which host bots are: China (11.4%), Brazil (9.2%), United States (7.5%), Turkey (6.3%), and Germany (6.0%).
  • Top 5 countries with the best ratio of security professionals to spam sources: Finland, Canada, Belgium, Australia (yay!), and the Netherlands.
  • The corresponding bottom 5: China, Azerbaijan, South Korea, Colombia, and Macedonia.
  • Top Spam harvesting countries: United States, Spain, the Netherlands, United Arab Emirates, and Hong Kong.
  • Fraud is rising as a cause for spamming:

    On the other hand “Fraud” spammers — those committing phishing or so-called “419” advanced fee scams — tend to send to and discard harvested addresses almost immediately. The increased average speed of spammers appears to be mostly attributable to the rise in spam as a vehicle for fraud rather than an increasing efficiency among traditional product spammers.

    As an anecdote to reinforce this, on one site i administer, i set up a dedicated subdomain which was purely designed to catch spam.  I placed some addresses in that domain on a web page, and within 1 day they had been harvested and 1 spam had been sent to each email address.  No email to that subdomain has been seen since.

Check out Project Honeynet’s full analysis.

Source: libertysys.com.au

More grist for the "long passwords" mill

For a long time, i’ve told my clients and friends that the best way to make a password is to write a short sentence or phrase. A recent study linked from Slashdot IT reinforces this. The executive summary: if you make your password 13 or more characters long, as long as it’s not a single dictionary word, it’s likely to be pretty safe from anyone who’s got less than US$10 million to spend on the problem, assuming current market prices for cloud computing CPU time.

Without going through all of my previous advice, the simple rule for passwords is: think of something you relate to your password, or just something that you think about a lot, and then write a complete phrase or sentence about it. Of course, none of this will save you from a wrench password attack.


Source: libertysys.com.au

"Just say no!" to e-cards

Richard Bliss recently blogged at Novell and on his personal blog with some great advice: don’t click on e-cards from your friends, and think about asking them not to send them at all, since the risks of clicking on e-cards vastly outweigh the benefits. Here’s another thought: real money spent on real cards, envelopes, and stamps shows that you’ve actually made an investment in reminding your friends and family of your regard for them. It’s much better for your online security, too! (Of course, one could argue that it is less environmentally friendly, but you can find cards and envelopes made from recycled materials.)


Source: libertysys.com.au