Tuesday, July 14, 2009

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.

Thursday, July 9, 2009

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.