Dark clouds on the AusCERT presentation

At this stage, I don't know if I will be presenting at AusCERT due to funding issues (bugger!). Which is a shame because I've done a lot of research onto cloud security which I'm now trying to figure out what to do with it!

I'm still undecided what to do as of yet - but I'm thinking of presenting some of it at AISA, OWASP or for DD clients at a minimum (it is Dimension Data content) after all. But I do know that everyone I've spoken to about this content is keen to start hearing more about it. I had one person at least suggest I should ask AusCERT directly (my presentation is not yet polished however and I missed the cutoff dates back in December as I'd only just really thought of presenting).

If anyone has any good ideas on cloud security and forums in which I can talk about it - be it to security professionals or other IT architects and CIO/management types, I'm open to suggestions.

Cheers,

- J.

Chip & PIN broken.

This is probably not getting the coverage that it deserves. It seems the authors are suspecting that this is news that the banking industry obviously doesn't want people to know (coverup?). But all the same, this news does need to be circulated.

I don't think its a coverup. I just think vulnerabilities like this should be understood so fixes can be made.

- J.

Cloud Security Issues Gaining Attention

The benefits of cloud computing are reaching a crecendo that cannot be ignored. The benefits are too enormous and too attractive to businesses. The security issues that the analyst had been jammering on about years ago, have now made their ways to media, courtrooms and boardrooms alike.

What am I talking about? I recommend you visit these two links.

The obvious issues of protecting data, ensuring it stays within national borders, issues of privacy, seperation of infrastructure yet maximising the benefits of cost reduction and infrastructure re-use are all coming together. The formation of joint organisations calling for the creations of laws and standards will serve to maximise the leverage of combined purchasing power.

What the hell does that all mean? I'm making two points:

1. It is a very clear and powerful example of where security has been engaged at the executive level and now forcing people to change the way we do business.  This is the way security needs to start engaging stakeholders, so pay attention! But more importantly...
2. The realisation that a standardised approach to ensuring the security of information is becoming paramount to the success of cloud computing. This means the development of formalised standards, audits, assurance programs, increase in tech and jobs. Not only is this great for security professionals but great for the consumer. 

I'm no economist, but I expect big spending in the space within the next two years and it will only go up. As more and more projects get off the ground, assurance will drive a significant component of this.

While there is the potential for the usual whitewashing of security assurance that I've seen over the years, it is clear that the usual slapdashery approach and adhoc application of IT controls cannot be ignored any further. When executives are forced to sit back and as tough questions - as well as taking a good long look at the affairs of their own house - changes will happen.

Big businesses like Telstra and CBA are now onboard with the Enterprise Cloud Buyers Council (ECBC) through the TMforum. There are other big companies and government groups looking at the cloud for solutions. While the TMforum caters more to the Enterprise Architecture crowd, I home that groups like the Cloud Security Alliance and other security minded organisations become involved. If you happen to read this and are involved in a security organisation, do try and get involved in this space.

On that note, version two of the CSA's Guidance document was released late last year. Recommended reading if you're working in with cloud computing in any capacity.

I realise this post isn't the most timely of news - my apologies. But I don't think many people have really thought about this to any real extent and I figured it was worth pointing out.

- J.

Security, Solution Architecture, Design Fundamentals - tying it together.

There are some things that need to be said about IT architecture - and by extension, security. There are some things I see are misplaced or otherwise forgotten, time and time again in IT architecture.

What I'd like to see in more solution architecture documents - and moreover, security attempting to bridge the gap and assisting solution architects out there:

1. Business problem - definition & solution: What problem does the solution architecture solve? What are the security threats at that level. How does security meet the business objective?
2. Requirements: Any restrictions that must be imposed on the design? Any constraints? Categorise them - Mandatory/Desirable/Discretionary. Based on threat modelling above, what are the security requirements? Are there any derived from existing policy? Also, how many of these requirements are set in stone? Too often people accept requirements as gospel without evaluating their foundation - without questioning them at all. You must pay attention here, especially when there requirements which have had drastic impacts on the design and imposing severe constraints. I once reviewed a design that had a very limiting requirement but sadly, nobody had defined the requirement clearly, nobody had questioned it with senior management to determine the extent of that limitation. The net result was a design rife with security holes and actually cost them hundreds of thousands of dollars more to implement due to increased hardware costs and software licensing - to say nothing of the cost of staff labour having to follow manual processes for what was trivial to automate.
3. Architectural Principles: Only a handful of places I've seen really provide good principles that are worth jotting down. TOGAF, Zachman (and by extension SABSA) have some foundational ones that we should evaluate as part of any solution. Simplicity is one principle I rarely see applied (I will get to that). There is a lot on offer from IT architecture frameworks and security consultants need to pay more attention here.
   
4. References: These don't necessarily have to be included within a Solution Architecture Design Document (SADD) but it helps to have done your research. Has the solution been attempted before? If so, what hurdles did they face? What lessons learned? Can the solution be copied? Are there any best practise guides out there on what the solution attempts to solve? It is rare that business problems we encounter haven't been dealt with before. The constraints or requirements are often the largest variable but the problems, in my experience, are often the same across different organisations, even different industries.
5. Keep It Simple Stupid (KISS principle): I draw this out separate to 3 because it needs to be called out. Security should be simple. The solution should be elegant. It should address the problem in one clean stroke. If you cannot find a simple solution to the problem, chances are you're doing it wrong.

This last point is the most important IMHO. Complexity is the bane of good security and most solutions are far too complex or at best, introduce elements of unnecessary complexity.

By looking to reduce complexity where we can, find simple solutions, you not only enhance the overall security of the design, you can potentially reveal substantial cost savings as well as find new respect with architects by providing a different viewpoint that they might not have considered previously.

These are just some of my thoughts that run through my head as I'm reviewing solution architecture. Hope this gives you all a little more food for thought.

- J.

Buzz - the deathknell for Gmail

How many people with Gmail accounts were furious when Google decided to activate Buzz and enable your account by default?

So much for don't be evil.

- J.

Automated Web Application Security Scanners

Jeremiah Grossman recently made this blog post, in regards to a comparison on automated web application security scanners.

I personally found the comparison a really interesting read. This is a topic that tends to spark a lot of discussion within organisations - certainly did amoungst my team. :)

I'd like to say that I am all in favor of these tools but there has to be some caveats -

1. They are no replacement for a human being.
2. They are no replacement for a skilled human being.
3. They are useful when conducting a normal web app pentest across a large number of sites is infeasible.
4. Do not rely on results which haven't been validated and put into context.
5. Be prepared to scrap them when they fail.

I'm aware of some enterprises using these within their security teams, often as a method for addressing web application security concerns. The problem is they aren't staffed with appropriately skilled individuals with penetration testing, software development and coding experience.

As this report demonstrates, these tools in point-and-shoot mode pose numerous issues:

E.g.

• They do not return all the vulnerabilities that exist.
• Many of the vulnerabilities found are actually false.
• The speed at which they operate is often woeful.
• The tools often require extensive time tuning to a given website.

The list goes on. And to some extent, this can't be helped. I mean even a human penetration tester isn't going to necessarily find every vulnerability. That's just the way it goes. They might come damn close but it just ain't the same.

But these issues can only be addressed by an intelligent penetration tester. One who can chuck the tool when needed, perform a SQL injection attack or modify a HTTP response on the fly via Burp proxy, etc. I mean nobody complains about having a skilled firewall administrator behind Checkpoint, or a DBA behind Oracle RAC, or sysadmin rebuilding a SAN array. So why the hell is there so much resistance behind hiring a skilled pentester often ignored?

If you're a security manager or application support or development manager thinking of purchasing one of these tools (or already own one), have a good long hard think about your reasons for purchasing one and how are you maximising its use. If you don't have a suitably experience penetration tester steering it, I would suggest that the money would be better spent scrapping that product and using the money saved on consulting to evaluate your software assurance processes and how you can better integrate application security testing into it. And if you cannot afford that, maybe you're better off outsourcing that next penetration test on a critical application rather than rely on automated tools to try and cover the lot and then make sense of the trainwreck.

- J.