Cloud computing

Has anyone found any good resources on cloud computing and security?

I recently found this site:
http://cloudsecurity.org/

But I'm keen to find any other good security resources in this space. Finding stuff and over and beyond what I consider "common sense security" is actually quite hard to find.

- J.

Security Exemptions

Originally I was going to write a post on business enablement but somehow in my mind this was a nice segway into security exemptions. So I'm going to blow off my original post and instead, blather about exemptions.

I am a firm believer that IT exists to support the business and that IT should always be about finding ways for business to operate quicker, more efficiently, cost effectively, etc. To that end, security should always be an enabler. But the reality is that this isn't as easy as it sounds and this is the difference between a pragmatic and lateral thinking security advisor vs an overly restrictive one - and the reason pragmatics are more widely desired.

I suppose when firewall changes, policy exemptions, risk statements are your daily bread and butter it is a bit hard not to be perceived as the "bouncher" or "naysayer". I've had more than my fair share of this. I've also seen people who are much harder to deal with than myself. I've seen people actively try and avoid going through me because I've been perceived as difficult to deal with. I've also experienced the reverse - situations where I've been approached because I've been perceived as the "lesser" evil. I've also seen some security staff really abuse their position and block work activity for a variety of random reasons (i.e. "we weren't formally engaged!", "it isn't documented!", "not enough time to review").

It is one of the most annoying parts of being in security because it typically results in one or more of the following:
a) someone ticked off (either the security guy approving an exemption or the person whose request is rejected)
b) more work for the security advisor
c) an interruption to his daily workflow.
This is as at a minimum.

I'm not going to proclaim loudly I get these right all the time. Far from it. Infact I probably would be the first to admit I make more than my fair share of mistakes - largely from the sheer volume of requests I receive and constraints on my time that render it impossible for me to attend to these as thoroughly as I'd like. But I strive to be always conscious of my contribution when I receive these requests (see my 'checklist' below). Whats more, I've learned a lot from both my own mistakes and those of my peers on how to handle these. I also believe in the "Law of Reciprocity". Thankfully I receive so many of these types of requests in my current role that I get plenty of opportunities to practise!

And without a doubt, I would say it is the hardest part of my job.

We never win friends when we say "no" - and sometimes looking at how you can enable the business takes some very, very positive thinking. Particularly when the request seems insane and/or delusional upon first glance (I.e. "Please allow 10.0.0.0/16 through the external firewall and disable our VPN. Kthxbai"). We're often given minimal information to work with and in many cases we are given the appropriate documentation, we often have zero time to review it adequately. Then we're expected to make snap decisions on that basis.

To make matters worse, if we get any of these wrong, a litany of "bad things" can occur -
- new security "holes" are introduced that could be exploited
- risks are vastly underestimated exposing the business to higher levels of risk
- "undocumented features" appear in your network, applications and systems
- spectacular audit and compliance failures with further consequential business impacts
- hostility in the workplace
- staff actively avoiding you or approaching higher level managers to supercede you
etc.
Guess who is typically the target when any of the above occures? If you said "security" you would be spot on.

Anyway, whenever we are approached for an exemption this is my 'checklist' of things that should be going through the security advisor's mind. It is probably not complete as this is all off the top of my head, as are most of these posts:

What is the business criticality of the request? Will the business be crippled through inaction by adhering to the policy or best practise? How much pain can the business take? Sometimes it is necessary to block requests but a good advisor must really look at the request on its own merit, evaluate it against the business unit, the work involved and the company as a whole. It isn't easy to do when you're under the pump.

Has a risk assessment been performed? Can the advisor do a risk assessment - formally or informally? What is the risk appetite of the organisation? Are they willing to wear a potentially high level of risk in future vs the immediate pain of a request not going ahead? Have they signed off on the risk? Is it captured in the right register?

Are the right stakeholders across this? Are they aware of the impact - both immediate and potential? Sometimes the right people are simply not involved. Are they aware of the risk assessment? Do they agree with it? Are they willing to accept the risk? Are there other business units (Finance, Privacy, Legal) who may take a dimmer view of things than Information Security?

What is the security maturity of the business unit? Do they have a history of repeatedly trying to put security off to "another day"? Are they constantly looking for the tactical, spot solution and never the strategic response? Sometimes dragging these units through the formal process is a necessity to call them to task. Othertimes, you may need to be more agile in your thinking and look for quick wins but formalise a long term action plan, balancing strategic requirements with tactical demands.

What are the policy, legal, regulatory demands? These requirements will vary based on organisation type, industry, size, country of operation, etc. etc. Their risk appetites will vary from organisation to organisation. As such, certain requirements can be more flexible than others. Businesses vary in their regard to maintaining security. A good security advisor knows the business, knows their risk appetite, what is necessary and most importantly, knows what battles to fight.

I don't have an solutions here unfortunately. I think this battle will be going on long after I've passed from this life. But here's some strategies I've found that help:

- Focus on building solid rapport with your business stakeholders. At least then when you reject their request they don't hate you in the morning and hopefully respect remains for your position on the matter, even if they disagree.

- Look for win/win outcomes . Look for ways to say "yes" rather than "no" (I have mentioned this before). Even just thinking "how can I say yes to this request?" can have a vast impact on your approach and how solutions are found.

- Try to understand the business requirement. The whole "walk a mile in someone else's shoes" thing. Beyond understanding the simple requirement, try to understand the other person's position and what they need.

- Look for tactical as well as strategic outcomes. Security comes in all shades of grey.

- Ensure you capture the risks appropriately. Even an email articulating the risk to the right stakeholder is better than not raising a risk at all. If you can raise it in a formal risk statement and risk register, good on you.

- Don't block a request out of spite. If you block a request, be clear on your reasons why.

I'd love to hear thoughts or tales from other security professionals on their approach to exemption requests - good, bad and ugly.

Cheers

- J.

Full Disclosure - Yay or nay?

I was following the recent ImageShack incident and in doing so found this article and this blog and it got me thinking - it is high time to post my $0.02 worth on disclosure of security vulnerabilities.

I don't want to delve too much into the article, but it got me thinking about my thoughts on security and why I do what I do, where do my beliefs lie, etc.

For the uninitiated, essentially there are three schools of thought -

Full Disclosure - Disclose all vulnerabilities when they are found, full details to replicate, no regard for timing, vendors to fix, etc.
Partial Disclosure - Disclosure of the vulnerabilities, with conditions. Conditions range from enough detail to find the exploit but not enough for script kiddies to copy/paste into Metasploit but enough for either a serious coder or someone with source code access to replicate. Sometimes the conditions could be around notifying the vendor, allowing some time to fix. Often termed "Responsible disclosure" (be it accurately or not).
Zero Disclosure - Vulnerabilities should never be disclosed, or at the very least, not without a fee.

There are compelling arguments for and against all schools of thought.

Full Disclosure proponents will argue that security is best promoted by being transparent about the findings and that by releasing them into the wild will force vendors to respond to the defects quickly. The idea being that vendors will release an exploit quicker than an attacker can exploit it. The arguments against full disclosure hinge predominantly that vendors have no chance to respond to the defects, and thus security globally is compromised.

Partial Disclosure suggests that disclosing the vulnerabilities is essential but there needs to be conditions attached in order to protect everyone's best interests. If a vulnerability is disclosed in full, it can be replicated by anyone. If it isn't disclosed to the vendor first, they are given no time to respond to the defect and provide a fully supported patch. Arguments against hinge predominantly on whoevers conditions attached to the vulnerability - which vary wildly to be truthfull.

Finally, there is zero disclosure. The reasons why vary from those given in the posts in the blogs above to the fact that full disclosure is little more about vulnerability researchers using public forums to trumpet their own horns and boost their own egos. Security isn't served by full disclosure as simply everyone is put at risk. The benefits of full disclosure are inherently outweighed by the overwhelming levels of risk that everyone is exposed to. Arguments against zero disclosure vary from exploits being kept secret, awaiting to be exploited by the more unscrupuluous hackers (a practise which already goes on) to promoting the ransoming of exploits to the highest bidder, leading to further exploitation and risk.

Honestly, there's more I could say on all three accounts but that's the issue in a nutshell.

So - what camp do I fall into?

Personally, I am a partial disclosure person.

• Disclosure your vulnerabilities, give the vendor the full exploit once you've found it.
• Allow the vendor an appropriate amount of time to remediate and release a patch (bearing in mind that the gears in large enterprise environments take awhile to turn, but they do turn).
• Stay in touch with the vendor, try to keep lines of communication open to track the status of your vulnerability.
  
• If you don't hear from them or an appropriate time frame to the release of the patc isn't given (subjective I know - but you want to give the vendor every opportunity) , disclose it publicly but don't give all the details. Just give enough to explain the root cause and provide remediation/mitigation advice.

Disclosure should never be (primarily) about getting the kudos. That should be an secondary benefit to promoting security. Also, I'm not saying vulnerability researchers shouldn't be paid either. I think they provide a valuable, if not essential service to the security community and the world at large. I think that mechanisms need to be put in place however to ensure that they are paid appropriately and their findings don't fall into the wrong hands.

Reading posts such as the Anti Sec blog got me thinking. It also got me mad. Not just for the fallacious logic, but for assuming that the motives of all security people is to make money and that our (ours being the security industry) efforts are to prop up undeserving corporate or government entities. Sure, there is that element and that the increasing commercialisation of the industry has attracted more than its fair share of hucksters. But I don't believe that's why we're in this.

Once upon a time, I was interested in security and held notions of some anti-authoritarian nature. Maybe I was interested because of my anti authoritarian nature. I don't remember. What I do remember is how it changed over time and my perceptions of information security became something entirely different.

These days, I like to think that securing or at least working to secure an environment is a far, far more difficult prospect than breaking into it. Far more. To the degree I think that when I read posts like Anti Sec, I can't help but wonder have they ever sat on the other side of the fence. I truly believe that if a black hat could work a week, doing what I do, they'd see there is a far greater challenge attached to working with businesses to fix their policies, procedures and practises - over and beyond the technology - to enhance security.

I understand that the proof is in the pudding - if you can still exploit software with an 0 day then all your policies, procedures, etc, can amount to nothing at the end of the day. But still, surely if our role in the world is to try and do what we can to make it a better place I cannot see how compromising systems and applications, selling off sensitive data to organised crime or supporting spammers, fraudster, child pornographers (such as Anti Sec proposed) helps to achieve that aim.

At least the traditional 'old school' hackers were in it for the exploration and learning, as much as self preservation.

- J.

Security Management

I've had a lot of time to think about what I consider to be the key success factors to good security management. I've only been doing information security for about six years - so it is not a huge length of time really. But I've worked in a lot of different environments over time and like to think I'm reasonably observant. I also pride myself on learning from the mistakes of others and not just my own.

So, with that said, I'm just going to post some of my own thoughts on this subject, but I'm very keen to hear what other people have to say. Particularly from those who have been doing this a lot longer than me.

Know Your Business
What are the key business operations, what are the key applications and environments, what are the business drivers and understanding the risks that jeopardise all of the above. What is the business strategy? What is the IT strategy? Are the two aligned and how can security help to meet these objectives?

Understanding The Organisations Risk Apetite
Who are your business stakeholders? What do they consider risky? Is it in line with the business (see above)? Do the stakeholders themselves pose a risk to the business?

Educate The Business
Make sure your business stakeholders know what the key security requirements to the organisation are, make sure they have a basic understanding of risk management and treatment options. Make sure your application support and development are aware of common security flaws and have or otherwise work towards secure application development. Ensure your infrastructure teams are aware of security best practise and all your IT teams work towards having secure standards, templates and repeatable processes to ensure security is done right - first time, every time.

Enable, Don't Restrict
Look for ways to say 'yes' to the business, rather than saying no. Find ways to encourage and support new initiatives and ideas. Find a way to implement security in such a way that you win friends, don't make enemies.

Simplify Security
Security is already perceived as restrictive and encumbent on the business, by the business. If you can find ways to build it into your processes and procedures, ensuring that security practises are automated as much as possible - then the battle is half won. Most security failures can be attributed to either human laziness or lack of awareness. Assuming your practises have been established with security in mind prior to automation, this means that the work is of a consistent (secure) standard.

Don't Stay Technology Focused
Not that the technology isn't important (obviously) but you must accept that the growing number of attack vectors and constantly evolving technology ensures it is almost impossible to stay on top of everything. Think about it - ten years ago, XSS and SQL injection were brand new. Ten years before that and web applications and VOIP were unheard of. What will the threats look like ten years from now? Can anyone of us honestly say for sure?
Having a good but broad technical skillset is more important than trying to be the best at everything. If you want to stay tech focused, nothing wrong with that - however I would then suggest you pick one, maybe two areas that you are willing to commit to. Even then, be flexible enough that you can change/adapt with the times. Certainly don't neglect your soft skills (see below).

Keep Up With Emerging Threats
This may sound contradictory to the last point but it really isn't. You don't have to understand the finer points of every new form of attack. However you must understand at a basic level how they occur, how they can be resolved and identify people with the skillsets - both in your organisation and outside of it - who can help you to plug those gaps within your business.

Soft Skills
Security is never a one man show. Even if you have no direct reports, your ability to implement security is more dependent on your ability to articulate, educate and influence than it is on raw technical skill. You can't do it all.
If you cannot specify security requirements or define the security position without upsettings your peers and stakeholders, then you are not helping security in your organisation. Learning how to deal and manage people is a vital skill if you want to do well in information security. So much so, the longer I work in this industry, the more convinced I am of this.

Know When To Be Firm
Part of being a leader is to know when to stand firm. Sometimes in security you have to take the hard line. Knowing how and when to pick your battles is crucial. Folding into unreasonable business demands or trying to constantly acquiese to the business never wins friends long term. If anything it can be detrimental to how others perceive you. Worse yet, it compromises security.

Knowing When To Delegate/ Know When To Take Ownership
Know when to delegate work but also recognise when you need to take the work on yourself. Especially the high risk items, the items of strategic importance to the organisation. Be clear on your reasons behind those decisions and stand firm on them (see above).

Have Passion
People who are empassioned are motivated. Their enthusiasm rubs off onto others. You have less uphill battles and more discussions around how to implement something rather than why.

Don't Take It To Heart
Security in the real world is an exercise in accurate risk management. The risks aren't yours - they are identified by security for the business to own. In that role, you are basically the messenger. If you haven't worked in security you may be suprised by the number of risks that are accepted on a daily basis.

Welcome to the 'real world' of information security. :)

Like picking the right battles to fight, you have to accept the ones you lost. Stay on top of your risk register as much as you can, try to make sure these risks aren't forgotten. Try not to take the risks personally (I personally struggle with this one) but just do what you can, with the resources you have and take solace in the fact that if your work has resulted in even one vulnerability being fixed, then you have made positive influence on your organisation and the world.

- J.

Web filters to censor video games

Unbelievable. The Government keeps changing its story!.

To summarise the current sequence of events:
- The Federal Government proposes Internet filtering.
- The Federal Government does not consult relevant industry groups or subject matter experts.
- The Federal Government does not clearly define scope (and in fact changes it constantly - first child pornography, then porn, then inappropriate content, then BitTorrent/P2P, now gaming).
- All discussions of testing have collapsed, all without a tier 1 ISP (in other words, nothing close to a representative sample).
- Any exposure of the blacklist will result in fines.

Seriously this sounds like an IT project going horribly wrong. I find it amusing yet sad... I don't know if this initiative will go anywhere. Despite their intent on setting themselves up 'Big Brother', thankfully, the entire initiative sounds like it is well and truly failing. Then again, it seems the Government can argue it is a roaring success without any success criteria. :(

- J.

The Pirate Bay to roll out secure €5 per month VPN service

Not that I condone piracy, but it looks like the Pirate Bay are now about to launch a public VPN service for $7USD/month..

Could be useful if/when this Internet censorship thing comes to fruition. Note - I said 'if' as well as 'when'...

- J.

Unruly patrons to get carded at city venues

Apologies for not posting much lately. My partner just gave birth to our first child. I'm taking some much deserved time off to be with them. :)

In other news: While this is not exactly information security I read this and immediately thought "security theatre".

- J.