Warning: include_once(/home/antonaylward/InfoSecBlog/public/wp-content/plugins/wordpress-support/wordpress-support.php): failed to open stream: Permission denied in /home/antonaylward/InfoSecBlog/public/wp-settings.php on line 304

Warning: include_once(): Failed opening '/home/antonaylward/InfoSecBlog/public/wp-content/plugins/wordpress-support/wordpress-support.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/antonaylward/InfoSecBlog/public/wp-settings.php on line 304
NASA « The InfoSec Blog
The InfoSec Blog

14 antivirus apps found to have security problems

Posted by Anton Aylward

http://www.theregister.co.uk/2014/07/29/antivirus_blood_splattered_as_biz_warned_audit_or_die

Let us pass over the "All A are B" illogic in this and consider what we've known all along. AV doesn't really work; it never did.
Signature based AV, the whole "I'm better than you cos I have more signatures in my database" approach to AV and AV marketing that so bedazzled the journalists ("Metrics? You want metrics? We can give you metrics! How many you want? One million? Two million!) is a loosing game. Skip over polymorphism and others.  The boundary between what actually works and what works for marketing blurs.

So then we have the attacks on the 'human firewall' or whatever the buzz-word is that appears in this month's geek-Vogue magazines, whatever the latest fashion is. What's that? Oh right, the malware writers are migrating to Android the industry commentators say. Well they've tried convincing us that Linux and MacOS were under attack and vulnerable, despite the evidence. Perhaps those same vendor driven - yes vendors try convincing Linux and Apple users to buy AV products, just because Linux and MacOS ran on the same chip as Microsoft they were just as vulnerable as Microsoft, and gave up dunning the journalists and advertising when they found that the supposed market wasn't convinced and didn't buy.

That large software production is buggy surprises no-one. There are methods to producing high quality code as NASA has shown on its deep space projects, but they are incompatible with the attitudes that commercial software vendors have. They require an discipline that seems absent from the attitudes of many younger coders, the kind that so many commercial firms hire on the basis of cost and who are drive by 'lines of code per day' metrics, feature driven popularity and the 'first to market' imperatives.

So when I read about, for example, RSA getting hacked by means of social engineering, I'm not surprised. Neither am I surprised when I hear that so many point of sales terminals are, if not already infected, then vulnerable.

But then all too many organization take a 'risk-based' approach that just is not right. The resistance that US firms have had to implementing chi-n-pin credit card technology while the rest of the world had adopted it is an example in point. "It was too expensive" - until it was more expensive not to have implemented it.

 

IAM – Basics – Policy

Posted by Anton Aylward

If there's one thing that upsets me when I see articles and posting to forums about policy, its mention of a "Password Policy". I have to step away from the keyboard, go outside and take some deep breaths to calm down.

I get upset because policy is important and developing -- and more importantly communicating -- policy has been an important part of my career and the professional service I offer. Policies need to be easy to understand and follow and need to be based on business needs.

If you begin with a list of policies, you end up adapting the the reality of your business - the operations - to the list. You are creating a false sense of security. You need to address what you need to control, and that is Identity and Access.

Lets face it, passwords, as Rick Smith points out in his book "Authentication", are not only awkward, they are passée - even Microsoft thinks so. More to the point, using passwords can be bad for your financial health.

They should be used with care and not as a default.

And they should most certainly NOT be entombed in a corporate policy statement.