tag:blogger.com,1999:blog-53881150225315345332024-03-09T19:55:07.292+11:00/dev/null - ramblings of an infosec professionalA chronicle of my journey and life lessons in the career of information security.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.comBlogger100125tag:blogger.com,1999:blog-5388115022531534533.post-31538133600682540172012-02-13T01:32:00.000+11:002012-02-13T01:32:14.134+11:00Sayonara!This is a farewell blog post. Although not the end of my blogging (I am not so easy to shut up as anyone that knows me will tell you) although it will be the end of this blog.<br />
<br />
I'm at a point of realigning and reprioritising my work and lifestyle choices to better support my goals. For a long time now this blog has been neglected. I have been writing for CSO magazine which in many ways, achieves the same aims that I intended for this blog. I have also resigned from Dimension Data and as of this writing, today is my last day. I feel this step enables me to be truly independent in my consulting and being able to offer opinions and services that will enable me to serve my clients more effectively.<br />
<br />
Similarly, I divert my energy into too many interests and activities and not all of them serve me. This blog is one example of that although I have plenty of other bad habits I am intending on stomping on. 2012 is my year for ass kicking and I intend on doing just that.<br />
<br />
It is my intention to start a new blog at some point (YA RLY!), and I don't say that idly. However, I am not sure when as I have many other aims that I need to achieve first. Part of that is focusing more on my technical work as I've mentioned before. Similarly my MBA is on hold for the moment as I haven't been able to give it the due attention and respect it deserves. I've certainly enjoyed it and I <u>know </u>I will finish it - but a man cannot serve to many masters. So right now, I am stripping everything in my life back to the essentials and focusing on what I love, doing what I love, in the manner consistent with how I think it should be done.<br />
<br />
When I first started learning MMA, my old coach taught me that the way you fight is to always push forward, never go backwards. So that's what I'm doing - fighting for what I want and always pushing forward.<br />
<br />
Life is too short. And one thing I've learned is that anything we truly want in life is definitely worth fighting for.<br />
<br />
I hope you've enjoyed this blog, please follow my updates on twitter @jloidl and my posts on cso.com.au .<br />
<br />
Best wishes,<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com2tag:blogger.com,1999:blog-5388115022531534533.post-25653640977218691092011-12-11T16:48:00.000+11:002011-12-11T16:48:58.303+11:00Grey Hat Python ReviewThis review comes almost a year late for a mate of mine extracted a blood oath to write a review on this book. My apologies for taking so long. <br />
<br />
- J.<br />
<br />
--<br />
"Grey Hat Python", written by Justin Seitz, a Senior Security Researcher at Immunity Inc, is a book which takes you through the process of reverse engineering using the Python language. He talks about automating simple tasks, writing fuzzers, debuggers, how to create your own hooks (soft and hard), sniffers and more. Does this book live up to its namesake? Overall yes, although I will say not without some disappointments- although not all are the author's fault.<br />
<br />
Firstly, the book suffers from a timing issue. It was released in 2009, around the same time as Windows 7 and new versions of Python (2.6 and 3.0 released relatively close together). The first issue is substantial as the author assumes that the reader is working in a purely 32bit environment. Now I know that a lot of developers that do, but I think this is a dangerous assumption given that 64 bit operating systems were not new and beginning with Windows 7 (with a much wider adoption than vista) a lot more prevalent. The second is arguably forgivable, given readers could use Python 2.6 without too much issue (although older Python functions might cause grief). <br />
<br />
With that said, the book wastes no time deep diving into the process by getting the author to explain how to setup your development environment and gives some Pythonic basics (e.g. explaining data types as they exist in Python when compared to C) and before long writing basic Python loops, delving into Assembly language and debugging basics. As you can imagine, this is not a book for programming noobs and you should have at least one language (the author assumes you have C at a minimum) under your belt before you trying this book, preferrably some Python know how. If you want a good book to learn Python, I'm a fan of Zed A. Shaw's "<a href="http://learnpythonthehardway.org/">Learn Python The Hard Way</a>" and the Python doco online when you hit his deliberate mistakes and trick questions.<br />
<br />
One criticism I read about this book elsewhere is how that it is a massive pitch for the Immunity Debugger. Firstly, I think this is an unfair criticism. The tool is widely used by security researchers around the world. I admit it isn't the only one but even with Dave Aitel's introduction, it is made quite clear that Immunity have chosen to standardise on the same language and same tools to better facilitate teamwork, automation and code re-use. Knowing who Immunity are and their reputation within the industry, you cannot really argue with their results. If you take that onboard, then you accept that you're learning from masters of their craft and they are trying to instill in you their work practices and techniques, not just code. The author is aiming to teach you the process and how to optimise it. In that respect, I felt this is much more valuable and that the book certainly achieved its aims in giving you and overview of the basics of research engineering and security research.<br />
<br />
Two areas I felt the book could have covered better was ASLR and how this affects exploit development. Firstly, I'm currently reading "The Art of Software Security Assessment" and that book was written in 2004 and touches on ASLR. Being 2009, this book specifically touches on DEP but doesn't even mention ASLR. I feel that completely skipping ASLR is a fairly unforgivable mistake. I realise this complicates the entire process but even a single paragraph explaining "No I'm not covering this and here's why" would have been better. If nothing else, the book could have stated "I will be touching upon these items in my sequel", promising to delve further into more advanced techniques and scenarios (ROP gadgets, heap spraying, sandbox bypasses, etc). Secondly, I felt the lack of any reference to 64 bit processors was also an oversight. I suspect the author began writing this book sometime prior to the 2009 release and subsequently this is what gives this book a somewhat dated feel.<br />
<br />
Taking all that aside, the author's style is simple, easy to follow and the book well structured logically. Each chapter seemlessly flows into the next and the coding examples seemed simple enough (I'd only gone through a few chapters, certainly not all of them so I cannot state for certain that the book contains no errors). This book is quite light at 181 pages (ignoring the Index) and definitely one of the lighter reads. Although for the price ($39.95 USD) I do feel it is on the steeper side given the above issues. If you're relatively new to security research and reversing however (which is clearly the target audience), then it's probably still worth it. Being honest, these areas are not my forte so the book felt "just right" for me. Take that for what you will. If you spend all day reversing then you will find this book far too light. I should also probably point out that I didn't pay money for this book, it was a gift from our good friends at O'Reilly via. my local OWASP chapter so I have no right to complain. :)<br />
<br />
Would I still recommend this book? Absolutely. I would also be amoung the first that would buy an updated edition or a sequel. I can certainly hope Justin Seitz writes another book (both a sequel and new edition would be great!). He has a great writing style and I think has a promising future ahead of him as a technical writer. I hope he continues to write books on this topic and explores it more fully.<br />
<br />
Overall rating? 4 out of 5.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com1tag:blogger.com,1999:blog-5388115022531534533.post-35792778096103403682011-11-29T04:52:00.000+11:002011-11-29T04:52:04.088+11:00Clarity<div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><b>“For me life is continuously being hungry. The meaning of life is not simply to exist, to survive, but to move ahead, to go up, to achieve, to conquer.” - Arnold Schwarzenegger</b></span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">I recently returned from Ruxcon and realised how much I enjoyed the conference and how much I enjoyed making new friends, catching up with old ones and making new acquaintances as well as the variety of talks which I found interesting. It always takes me a few days after to really dwell on events and consider what I walked away with. This year, I walked away with a few things - a clarity of purpose that I don't think I've had in a long time. My attendance this year triggered an epiphany for me that made me accutely aware of where my growing frustrations with certain things in my life. E.g. - what I am doing, what do I want to be doing, what would I rather be learning, balancing that with other personal commitments, financial goals, etc. I think at times, I've also directed that frustration at the wrong people in my life. So, if you read this and realise you've been on the receiving end of me griefing you - sorry about that.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">I'd not posted much since my Management vs Technical post as this has consumed a good portion of my brainpower trying to figure out what route I was going to take. I've lost track how many times I've been asked the question too. So I've made the call, although some might call it taking a third option. But more on this later.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Sometimes, the only clarity we get is the realisation of what we enjoy vs what we don't enjoy. Or maybe that's the point and always has been and I'm just a slow learner.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Anyway, here's what I've learned - especially in the past two years in no particular order:</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><ul style="font-family: Arial,Helvetica,sans-serif;"><li><span style="font-size: small;">I enjoy learning both technical and managerial work and will create my own opportunities to learn both areas as I see fit;</span></li>
<li><span style="font-size: small;">I have realised the joy of working with my hands again (so to speak) doing technical work (after too much time largely hands off);</span></li>
<li><span style="font-size: small;">I am, and always will be, a self-directed learner;</span></li>
<li><span style="font-size: small;">If I am ever going the managerial route it will won't be for someone else's business (at least I don't see it today);</span></li>
<li><span style="font-size: small;">I enjoy talking security to non-security folks;</span></li>
<li><span style="font-size: small;">I enjoy reading technical security theory;</span></li>
<li><span style="font-size: small;">I really dislike drawing up security policies (why can't people just people buy the ISO27001 and 27002 standards and start reading??);</span></li>
<li><span style="font-size: small;">I really dislike "light and fluffy" security work without a strong technical underpinning;</span></li>
<li><span style="font-size: small;">I really dislike talking security strategy with businesses that have no desire to be strategic or even take security seriously;</span></li>
<li><span style="font-size: small;">I really want to work alongside my friends doing really, really cool stuff;</span></li>
<li><span style="font-size: small;">I want my work to leave a lasting impact;</span></li>
<li><span style="font-size: small;">My attitude and career goals and aspirations really don't fit well into a corporate hierarchy (e.g. my sense of fashion on "casual" Fridays :);</span></li>
<li><span style="font-size: small;">I have strong anti-authoritarian tendencies - at least for rules that make no sense to me;</span></li>
<li><span style="font-size: small;">I really don't want to work 40hrs a week in an office away from my family (although I'll gladly do more if I can at least be near them);</span></li>
<li><span style="font-size: small;">I have business interests outside of infosec that I want to see through (eventually);</span></li>
<li><span style="font-size: small;">Infosec is a great industry full of always interesting work once you get past the cynicism of most people in it :).</span></li>
</ul><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">There it is. Perhaps its not much a wish list but its enough for me to give me focus.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">My blog for a long time has focused very heavily on what businesses need to do to make themselves more secure. I've arrived at the conclusion that by and large, its not really rocket science (I did admit I am perhaps not the fastest learner). It just comes down to getting commitment and support from the businesses' executive manager and cascading that down. Once that commitment exists, as long as it is staffed by genuinely, well intentioned people that genuinely care about the business, things will improve. Perhaps not overnight and not without setbacks. Hell it may not even resemble anything best practise - but slowly and surely it will. Thankfully, I've been blessed to see this throughout my career enough times to know it to be true. If that doesn't exist or cannot exist, then security is doomed to fail and you're working under that management chain, you should probably GTFO before its too late. Thankfully consulting is a great way to study what you love and help others without being so constrained by those politics. So this lifestyle agrees with me - at least for now. :)</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Anyway, thanks to those who helped me to find this clarity. You know who you are. My blog will start to change focus more and more to topics which match my interests. I will still write for cso.com.au - I must admit the time I spent here normally is being invested moreso in my articles there. Nonetheless I think my change in focus will lead to some equally interesting posts here.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">- J.</span></div>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com2tag:blogger.com,1999:blog-5388115022531534533.post-57056614055125531082011-09-02T17:23:00.001+10:002011-09-02T17:23:56.794+10:00UpdateHi all<br />
<br />
I've been severely negligent with my blogging lately. And this post is not one of my more detailed ones. <br />
<br />
I've had an exceptionally busy few months - both outside of work and at work. At some points, you just gotta keep your head down, bum up and only surface when you need air. And that's exactly what I've been doing.<br />
<br />
I've recently had the privilege and pleasure writing for cso.com.au - and so some of my time has been spent submitting articles for them. Hopefully you will be reading more of them soon. I've had my hands in a lot of pies outside of work in other non-security endeavours, which have been taking a lot of my time but no less rewarding.<br />
<br />
A lot has happened this year, between the rise and fall of Lulzsec, Anonymous, Wikileaks and the ongoing Cablegate saga, changes in Australia with regards to ratifying the Convention on Cybercrime and more. I know this phrase gets thrown around a lot, but the world really is changing at an increasingly faster pace than we are able to adapt. Events are unfolding before our eyes that require our attention and yet, so much is happening to take our eyes off the ball.<br />
<br />
If I can post one random thought, if what you see troubles you enough to want to act on it, pick one issue closest to you and run with it. You can't fight forest fires on multiple fronts. You can only fight one fire at time. We all have our gifts and we need to be using them in ways that can yield the best efforts for the least amount of effort.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-49239225550909161692011-05-30T23:51:00.001+10:002011-05-31T00:04:07.819+10:00Management vs Technical Career<div style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div style="font-family: inherit; text-align: center;"><div style="text-align: center;"><span style="font-size: x-small;"> <i>"Everybody's a genius. But if you judge a fish by its ability to climb a tree, it'll live its life believing it's stupid." - Albert Einstein</i></span></div></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">I think I held off from writing this post for a long time. But it seems to keep cropping up this discussion wherever I go, sometimes in the most unlikely of places, so I felt it is probably time to post something on this subject (given the title of this blog). I think part of me wanted to deny that it was a binary decision. But ultimately, there is no escaping it. Over a long enough time line, all people in IT, regardless of their discipline, have to make the call - will I go take a managerial path or will I take a technical career path?</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">For some people, the way forward with their career, their lives, whatever – is perfectly clear cut. These enviable people have a clarity of purpose that eludes many people, myself included. I wish I was one of those people, but sadly I am not. </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">After you work in IT long enough, you reach a point where you realise that a decision needs to be made about where you see yourself heading. I’m sure some people just plod along with their lives without a second thought, but I think anyone with a degree of foresight gives this some consideration. And as they say, a life without reflection is not a life worth living.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">For those of us who travel this road of uncertainty, I can throw up a number of triggers I can say I’ve seen (either first-hand, or second-hand through observation of those around me) that prompt this evaluation:</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><ul style="font-family: inherit; margin-top: 0cm;" type="disc"><li class="MsoNormal"><span style="font-size: x-small;">Realising you are not as technical as you thought you may have been and evaluating the skills gap to get to where you want to be;</span></li>
<li class="MsoNormal"><span style="font-size: x-small;">Realising you the most organised person in your entire team (if not division) and capable of juggling six balls for long periods of time without dropping one, even if you actually enjoy the technical aspects of your job;</span></li>
<li class="MsoNormal"><span style="font-size: x-small;">Realising that the ongoing technical study is consuming a lot of your time and its much harder with a girlfriend/wife/kids/etc or if you want to develop other areas of your life;</span></li>
<li class="MsoNormal"><span style="font-size: x-small;">Realising you want more recognition for your work or more pay;</span></li>
<li class="MsoNormal"><span style="font-size: x-small;">Turning 30. </span></li>
</ul><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">This list is not exhaustive by the way, nor is it intended to be.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">In trying to see what was out there on this subject, I found some interesting links people may find reading.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><ul style="font-family: inherit; margin-top: 0cm;" type="disc"><li class="MsoNormal"><span style="font-size: x-small;"><a href="http://www.spe.org/twa/print/archives/2009/2009v5n2/4_Forum.pdf">Technical vs Managerial Careers: What experienced professionals say</a></span></li>
<li class="MsoNormal" style="color: blue;"><span style="color: windowtext; font-size: x-small;"><a href="http://secondnegative.com/archives/2005/07/14/management-vs-technical/">Management vs. Technical</a></span></li>
<li class="MsoNormal"><span style="font-size: x-small;"><a href="http://manasgarg.blogspot.com/2004/12/technical-ladder-vs-management-ladder.html">Technical Ladder Vs Management ladder - Which one is for me? Part 1.</a></span></li>
<li class="MsoNormal"><span style="font-size: x-small;"><a href="http://nextgenerationofleaders.com/?p=465">Management Career Ladder Vs. Technical Career Ladder</a></span></li>
<li class="MsoNormal" style="color: blue;"><span style="color: windowtext; font-size: x-small;"><a href="http://www0.hku.hk/bse/tu_careerpaths.pdf">Career Paths: Technical vs Management</a></span></li>
</ul><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">(The first link in particular I <b><i>strongly</i></b> recommend everyone should read - and I refer to it heavily throughout this post).</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Now in some of the above, I’ve seen the economic rationalisations why certain careers earn more than others. Robert Kiyosaki in “Rich Dad, Poor Dad” spoke of this with regard to what his rich dad taught him about sales. In “</span><span style="font-size: x-small;">Technical Ladder Vs Management ladder - Which one is for me? Part 1” this is explored. I think it is absolutely accurate and fair to say that management folks should be paid more. Technical specialists may not agree to paraphrase something I once read (Kiyosaki I believe) “the larger problems you solve, the more you earn”. The simple fact is that business people, folks in management, sales, typically speaking, solve larger problems than technical folks. </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Now I’m sure many will cry out and point out the guys like Zuckerberg and how he started Facebook, Gates with Microsoft, Dell with Dell Computers, Bezos and Amazon – but while these guys were technical, let’s be clear that they used their skills <i>to solve a problem</i>. Sometimes, solving a big problem. In some cases, more than once. And ultimately, at some point, they become managers. Can you, as a techie, go out with a brilliant idea and make squillions? Absolutely, the reality of it is that it is much harder than you think (in studying innovation for uni I can assure you that it is – by a long shot). Also, even if you do become that guy, chances are you'll need to manage. The best instances I've seen are where the technie still gets to run amok is where he/she becomes the CTO, recognises he/she does not want to do management and then builds a management layer around him/herself to take away the headaches but these examples are few and far between (Hint: I can readily think of two examples, and two alone).</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Also, if you’re aiming to be a good techie, the reality is you can pretty much ignore anything to do with management and business, hone your skills until their razor sharp, go to market as a contractor and make a salary at a level only senior executives can dream about (I had one friend tell me recently he is making five figures a week as a contractor but let me tell you, he has no time to spend it).</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">What is the downside of working in tech? Well the time investment to maintain current is actually quite steep. Technology is changing at a faster and faster rate. People who were generalists ten years ago are specialists today. What will happen in another ten? What happens when techies get into relationships, get married, have kids, have to tend to a full house, dirty nappies, screaming children, nagging spouse, family obligations, etc? The constraints on your time will demand your attention be spent elsewhere and they only grow with time. If you aren’t doing it then for the love of the work, then you may find yourself looking for something a little easier.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">But is it easier? The first survey indicates respondents from <u>both </u>tech and management backgrounds indicate that techies have a better work/life balance. So there it is. Does that suggest then that techies looking to find a role which has lower degree of upskilling should be looking to management at all? The survey suggests they shouldn’t. In my experience… I think it depends on the level of seniority you aspire to. Middle managers certainly, not. In which case you may want to find that sweet point where you can take the breaks off a bit and get your tech on at work and still have a life outside of work. That could be a technical role, it doesn't have to be management. If you want a salary increase but want to do the same level of work, then a line manager is pretty much what you're staring at. I don’t think this is necessarily as easy to find however as one might think. For every manager that I know that aims to cruise, I know of 5 more that do more work outside of work than they ever did as a techie. Then again, the oldest techs I know still spend considerable time on the tools as much as because they love the challenge (and as much as because they're surrounded by ineptitude and can't trust anyone else to do it) and will probably work themselves into an early grave. But, based on my anecdotal experience, I'll give techs the benefit of the doubt on the work/life balance equation.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">So lets assume that money isn’t really a consideration as to whether you should move into the manager track or not (given that it is unlikely to be a deciding factor unless you plan on becoming C-level and drawing in a bonus or equity payments ontop of salary). Also, lets further assume work/life balance isn't an issue, with techies again pulling out in front. Why would you move to management? </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Influence, according to the survey. 73% of managers felt that they had more pull over corporate decisions where as only 45% of technical staff felt the same. I’ve never been a manager directly, so I feel I can’t really say, but I can say I became a lot more interested in it after working under the sufferance of some really bad ones. Once you see the benchmark for exceedingly bad management, it can certainly inspire you to take that route, even if for no other reason than to save you from someone else’s incompetence. That, to some extent was why I started my MBA. Now while I enjoy the learning as I go through the degree (I’m a sucker for learning in any form), the most I can say I’ve gained so far is that now I am even more critical of bad management decisions than I ever was before. Although, I'm sure all of us at some point think we could do a better job of something than those above us. :) I would agree with the above - wanting to have a greater say in how things are done is the greatest motivator for people moving to a management role.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Whether one should go technical or managerial, I don’t believe that you need to be perfect at one or another to make the decision. I do think, however, it requires a commitment. And therein lies the rub for those who are straddling the fence. </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">The irony is, if you have decent skills, even if you are not the best in your field, but you are committed to a lifetime of self improvement and passionate about what you do, taking the longer view, you will be fine. As the survey points out, technical experts are usually shielded from a economic downturn and rewarded in the upturn. Having seen this first hand, I would concur. Having said that, <i>I’ve seen a lot of technical staff who were not at the top of their game culled when times were tough</i>. I take the survey to be a caution to those who aren’t good at what they do to really lift their game, or failing that, channel their skills into an area where they will succeed. I have also heard of stories where people who were not technically brilliant had skill beaten into them over time. I have heard this repeatedly by technical people (including technical managers) with over thirty years of industry experience and I really trust their judgement on this. This suggest that technical skill can be trained (even if critical thinking and analysis are harder to come by). </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">So, assuming, tech skills are easier to acquire and maintain, you get better work/life balance, near equal pay (assuming you get a contract role) then why else would you go for management, if influence on corporate decision making wasn’t a factor? Maybe you are just playing to your strengths. I have one friend who is a manager and making a good career for himself of it and for the longest time, he wanted to move into a more technical role. I think it has taken him close to two years of full time management (and many years prior of 'delegated' manager) for him to start to accept he is really very, very good at what he does, even if it is not something he would have necessarily picked for himself. Is he happy? Hard to say. I don’t believe he is miserable, that’s for sure. He seems to have a good work/life balance however (for the most part). </span><span style="font-size: x-small;"> </span><br />
<br />
<span style="font-size: x-small;">The stats in the survey also suggest this is the case, with only 21% of managers actually stating that they would prefer to go back to a technical career. However, as a caution for those who go this path, “lack of technical experience” stemming from a “premature management” jump to management as well as “financial packages too established to risk” were the main reasons cited why managers wouldn’t jump back. So if you’re thinking of a career in management, the survey indicates that 11-15 years in a highly technical role is recommended before you switch to management because it allows greater flexibility in switching back to a technical role during a harsh economic climate. Managers with less experience technically will not have this degree of flexibility. Also, start socking more money away if you move into a senior role and be sensible with your cash.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Some people, like my mate, I think are drawn to management because they organised. Some because they are natural leaders. One mistake many make is to draw parallel between the two when infact they are not synonymous. It has been my experience that there are managers out there, but very few are leaders. Some people with these skillsets are better drawn to management and infact suited to it. Should they do these jobs however if they still enjoy the technical aspects of their role? What if they excel in these areas? Should they then play to their strengths and do what they do well? What if they don’t like it? </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">I’ll be honest, I don’t have the answers on this. I don’t even know if anything I’ve said above can help but I certainly have some advice which I think will be helpful no matter where you are on this path. These are things I have found helped me to get some focus on my path:</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit; margin-left: 36pt; text-indent: -18pt;"><span style="font-size: x-small;"><b>1)<span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"> </span></b><b>If you haven’t tried management, it might be worth trying it before you knock it. </b></span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">According to the survey above, 48% of respondents with previous management experience were less like to change jobs for a crack at a management position as opposed to 66% of those without management experience. This suggests statistically that the grass is greener on this one. So let’s say you try a management role only to find you utterly hate it. Awesome! Would you actually say the experience is wasted if you can make an informed decision on whether it is for you or not? </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit; margin-left: 36pt; text-indent: -18pt;"><span style="font-size: x-small;"><b>2)<span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"> </span></b><b>Work in different roles (in different companies)</b></span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">The same survey suggests job rotation is the key to a long career within an organisation and I can certainly say I’ve seen that within Dimension Data. There are more people have been here for 5 years - 20 here than any other place I’ve worked (and I’ve worked for universities extensively which have amazingly long tenured people). I get to work with people who have some amazing skillsets that you simply don’t find in other places. One guy I work with has worked as an architect, engineer, consultant, system admin and a programmer and I don’t think I’ve ever met anyone with a more interesting technical skillset. </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Even if you don’t change jobs outside often, job rotation within your existing employer can be a highly rewarding experience and from a purely managerial view it actually makes sense. That said, I believe working in multiple organisations is something you need to do, hence I’ve added it to the above heading. </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">I believe you need to work technical roles in different environments to truly get a sense of your worth and whether or not that career ladder is for you because you need to get a sense of where you rack up against your peers. Don’t listen to what one organisation, or one person, tells you about your skillset. It is very easy to become pidgeon holed and listen to what someone else tells you what you are worth and not what you believe you are worth. That's not just sound career advice though, that's life advice (unless you suffer a mental illness or the <a href="http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect">Dunning-Kruger effect</a>).</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit; margin-left: 18pt;"><span style="font-size: x-small;"><b>3) Get leadership experience outside work</b></span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Two of the above links suggest leadership experience outside of work might be beneficial for technical people to get a taste of whether it is for them. The reason doing it in an environment outside of work is that there is less career impact incase it goes wrong. I can’t say I’ve tried this, but it would be remiss of me not to include it as an option and it does make sense.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">I have one friend who has been co-founder and lead developer on a major project. That is a good example. </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit; margin-left: 36pt; text-indent: -18pt;"><span style="font-size: x-small;"><b>4)<span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"> </span></b><b>Do what you love</b></span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">I am a firm believer in the phrase “do what you love and the money will follow”. I have friends who have worked in some amazing careers. My friend Darren over at <a href="http://www.stylus-monkey.com/">Stylus Monkey</a> is a good example of this, and to this day I think of him as my role model (BTW follow him on Twitter and read his blog – his posts are relevant to anyone, irrespective of their role). Whatever you do, you must do with passion and Darren is the embodiment of living your life with passion. I admire him for having the balls to follow his dreams. Most people never do. You may take a few different roles to find something that stimulates you. But whatever it is, find it and run with it.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit; margin-left: 36pt; text-indent: -18pt;"><span style="font-size: x-small;"><b>5)<span style="-moz-font-feature-settings: normal; -moz-font-language-override: normal; font-size-adjust: none; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"> </span></b><b>Be the best at what you do</b></span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">All the evidence suggests that during an economic downturn it is the star performers who are shielded. If you are passionate about what you do, strive to be the best at what you do, you will receive due compensation for what you love and those above you will look out for you.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Like I said, I don’t know if this helps anyone. But I think reading the surveys, reading experts who have walked down this line and talking to other people who have made this call and quizzing them over the how, when, where and why they made the call is always beneficial. Finally, irrespective of what side of the fence you fall on, I hope everyone reading this at least made the decision to be a leader in their field.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">Cheers, </span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;">- J.</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div><div class="MsoNormal" style="font-family: inherit;"><span style="font-size: x-small;"><br />
</span></div>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com59tag:blogger.com,1999:blog-5388115022531534533.post-9316669487769394832011-05-22T18:26:00.002+10:002011-05-22T18:46:01.425+10:00VUPEN vs Google and the consequences for IT SecurityI've been largely pre-occupied with other work as of late (read: university assignments), but not wanting to discuss AusCERT I did however want to touch on the VUPEN vs Google debate.<br />
<br />
For anyone that had missed this, simply put, a French security research firm claimed <a href="http://www.youtube.com/watch?v=lE0vwbtBjz4">(displaying video footage) </a>that they had cracked the Google Chrome sandbox, allowing arbitrary code execution. What makes this news worthy however is their refusal to disclose the details to the vendor and only provided the details to their clients (mostly French government, law enforcement, military types) who paid their subscription. For what purpose, we can only guess.<br />
<br />
For the overview, see below:<br />
<ul><li><a href="http://isc.sans.org/diary.html?storyid=10852">ISC SANS discusses VUPEN's disclosure of Chrome Bug</a></li>
<li><a href="http://krebsonsecurity.com/2011/05/security-group-claims-to-have-subverted-google-chromes-sandbox/">Brian Krebs - Security Group Claims To Have Subverted Google Chrome's Sandbox</a></li>
<li><a href="http://dankaminsky.com/2011/05/13/v-vs-g/#intro">Dan Kaminsky - VUPEN vs Google</a></li>
</ul><br />
Now, I'm not getting into a moral debate surrounding disclosure, but what I wanted to highlight firms selling 0day vulnerabilities is not new. <a href="http://www.spartacusx.com/the-secret-deal-between-endgame-and-hbgary/">Endgame Systems was dragged into the limelight</a> when HBGary's treasure trove of emails was leaked to the public when it was revealed a multi million dollar contract for selling zero day exploits. This is perhaps the first instance of where a previously known but underground industry practise was exposed very, very publicly. Based on the content and context of these leaked emails, we can only presume they were developed for offensive (largely illegal) purposes.<br />
<br />
What I found largely interesting is the lack of political fallout for Endgame Systems. On the contrary, apart from a handful of negative news, most of the rage was directed at HBGary. But the point I'm trying to make is that Endgame Systems, very carefully and deliberately - did not want to draw any attention for these activities. Yet, VUPEN is perhaps the first firm we've seen who has taken an active stance to promote their technical capability in the production of 0days. And to repeat myself, it is ironic that they are copping all the rage from the public for their disclosure while Endgame Systems does not.<br />
<br />
This raises two interesting points of concern -<br />
One, the relative hypocrisy of an industry that is willing to slam one company for openly acknowledging their capability and is punished yet another seeks to hide it and goes relatively unscathed;<br />
Two, and perhaps more importantly, could this represent a new era whereby exploits will begun to be sold openly?<br />
<br />
On the first point, I have my suspicions but it seems odd that it is perceived as socially acceptable for one country to have this capability and yet, not for another. It reminds me of the nuclear arms proliferation debate really.<br />
<br />
On the second point, the publicity stunt that VUPEN pulled presents something we've not seen before (at least, not that I can recall - please correct me if anyone can think of a more public example).<br />
<br />
As the legalities of security research in which vulnerabilities and exploits (sorry, "Proof of Concepts" :P) are created vary from country to country. This means that their "legitimacy" (perceived vs real) could have a very profound and transformative effect on the IT security landscape.<br />
<br />
Will this force IPS vendors into bidding wars for 0days to update their signatures? Will this force vendors to create pay money as a form of "hush money"? Will governments seek to impose a tax on software developers who create faulty software or perhaps a more likely outcome - rushed legislation to ban vulnerability research and exploit development (further driving up the black market value and driving the industry further into the dark). <br />
<br />
All food for thought but I would not be suprised if this activity becomes increasingly commonplace.<br />
<br />
So yeah, watch this space.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com3tag:blogger.com,1999:blog-5388115022531534533.post-41993554017431241062011-05-04T21:29:00.000+10:002011-05-04T21:29:16.246+10:00The Risk Management Lie<!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w:DontGrowAutofit/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" LatentStyleCount="156"> </w:LatentStyles> </xml><![endif]--><!--[if gte mso 10]> <style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
</style> <![endif]--> <br />
<span style="font-size: small;"><span style="font-family: Arial,Helvetica,sans-serif;">Rumors of information security evolving as a process and an industry is really a mixed bag. On one hand, I’ve seen first hand the benefits of improved governance. This helps to ensure people can’t make adhoc changes to production environments and should those environments change outside of authorised change windows and there is no corresponding change record, the change was unauthorised. </span></span><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">On the other hand we still don’t track risks well. We don’t REALLY understand them. We don’t classify them well. And for those who are able to do this even partially well, their Excel spreadsheets fall far short of the capability of tracking chained exploits and how can lead an enterprise to ruin.</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">The models we use to track IT security risks are – to my thinking – like soothsaying. It reminds me of witches from centuries past, sacrificing chickens and casting bones in an attempt to augury the future. For all our metrics, for all our “likelikood x impact = risk” crap, we may as well be doing the same.</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Is it wrong to use these methods? Well, no. At the end of the day, something is better than nothing. If these methods at least give the organisation you’re working with some sort of awareness of the risk you are taking onboard by choosing not to remediate a finding, then that is a good thing.<span> </span>Not undertaking a risk assessment is like making a call not to bother getting your car serviced since you were overdue three months ago and the car is still running fine now. Sure, it might SEEM fine, but that’s until the wheels fall off (so to speak).</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Three issues I see as being critical to the failure of risk management as a discipline (specific to information security): </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><b>1) Inability to track and measure vulnerabilities which can be chained</b></span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">The lack of organisations to full understand chained exploits and how they can be exploited (and even security professionals might easily miss how someone is able to chain them too I might add) is one of the greatest limiting factor of risk management. </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">We can talk about a missing patch or an exposed, vulnerable application and explain what is the business impact if that is compromised. What we can’t do well is look at <i>all</i> the other vulnerabilities in the environment and suggest methods how or why that singular event could be triggered by other risks inherent to the environment.</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><b>2) Inability to accurately define and measure TRUE risk</b></span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">I’ve seen discussions over which risk management method is better. I’ve seen FAIR advocates. I’ve seen ORM described as the defacto standard (Ostrich Risk Management for the uninitiated). At the end of the day its all the same. We really <i>don’t know. </i>Risk management is really the art of sticking your finger in the air, applying models that do not translate well to IT risks and taking a quasi-intelligent guess at the risk. </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">This isn’t a field like say the incident of cancer or natural disasters are tracked for insurance purposes. We don’t know how often SQL injection is exploited globally on a per IP address basis. We have even less data to narrow the field of inquiry down to a geographic region, let alone how often we see a singular enterprise being hit (if you’re one of the few organisations that do track this sort of data, you have my respect). What about risk impact? When someone asks you what is the likelihood that SQL injection will occur on a given server, what are you referring to? The fact that someone uses SQL injection to copy the data and onsell it? Tamper it and hope you won’t notice? Trash the server? Or use it as a bastion host to conduct further attacks? Do you draw up risk assessment for each scenario or only one? Each example given has a highly variable risk, depending on the business purpose of the application that relies on said database. Some organisations (e.g. agencies within government/military) may rely heavily on confidentiality. Others may rely on availability (e.g. banking). Others yet again, integrity (e.g. universities). </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><b>3) Ongoing treatment and management of risks</b></span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Ultimately I see very little organisations and businesses can do to address the first two points, apart from being aware of the inherent limitations of risk assessment we use today and try to keep an open mind with them. This third point is something you can all do <i><u>today.</u></i></span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">In many instances I’ve seen, risks are often stuffed into spreadsheets with signatures and never again touched. Hey the business accepted the risk – it’s a done deal, right? Well no, not exactly.</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Risks can change. You need to review them. In the course of a year the environment may have changed radically. Or perhaps even superficially, but in either case, enough to introduce new risks which could alter the original risk score. This is where an opportunity exists to better understand how chained risks can be introduced into your environment. </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Sometimes, all we can do is go back and review the risks that have been formally accepted. If you can go back and see there is a series of risks that could be chained, use those to propel your security program. If you need to, develop a proof of concept. Show the business what these risks can mean to their business and how they can be exploited. Explain who would want to target them that way and why – particularly if the risk warrants it. You don’t want to take this approach with every risk, but if you see that chaining presents a greater aggregate risk than whats on your spreadsheet, then you have an obligation to speak up.</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Overall, I wish I had a solution to risk management in an infosec world – but I don’t. I don’t like how the process is governed by auditors who see each vulnerability as a discrete risk without any perspective of the larger whole. All we can do is point out these limitations and try to work with them. </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">In closing – </span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">Don’t accept risk management will solve your problems. You still need to find the problems first. You still need to understand them, capture them and take ownership of them. Even then, you still need to be mindful that you may have overestimated or underestimated the scope of the problem. And this is why you need to constantly review them.</span></div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div class="MsoNormal" style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">- J.</span></div>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com4tag:blogger.com,1999:blog-5388115022531534533.post-30746117458482070492011-05-04T00:52:00.001+10:002011-05-04T00:54:26.442+10:00The best defence is a good offense<div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">I recently read two articles that made me consider is the goals of cyber security shifting - or perhaps more precisely, could it shift? </span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">The articles:</span></div><ul><li><h1 style="font-family: Arial,Helvetica,sans-serif; font-weight: normal;"><b><span style="font-size: small;"><a href="https://www.infosecisland.com/blogview/13430-China-Advances-Cyber-Warfare-as-Primary-Strategy.html?sms_ss=stumbleupon&at_xt=4dbf2b81161e9c55,0">China Advances Cyber Warfare as Primary Strategy</a></span></b></h1></li>
<li style="font-family: Arial,Helvetica,sans-serif;"><h1 class="title"><span style="font-size: small;"><a href="http://threatpost.com/en_us/blogs/glass-dragon-chinas-cyber-offense-obscures-woeful-defense-042711">Glass Dragon: China's Cyber Offense Obscures Woeful Defense</a></span></h1></li>
</ul><h1 style="font-family: Arial,Helvetica,sans-serif; font-weight: normal;"><span style="font-size: small;">There's a heap relating to China that are worth reading on Threatpost - in particular anything relating to Dillon Beresford's dubious "research" into China's security.</span></h1><span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">What is emerging here is </span><span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">rather scary pattern - it would seem (at least based on the media at hand) that China are pushing an offensive security agenda as not only part of a national defensive strategy, but also an economic policy for national benefit.</span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">It's a no brainer that cyberwarfare offers truly asymetric capabilities. Success is not based on which force has the larger army or resources to throw at it but often those who have the most skills and display the greatest intent and capability in using them ("who dares wins" indeed). Economically, this is an awesome capability too. I read a report on innovation (by Cisco) awhile back (sadly no, I cannot find it dammit) but one of the things that was discussed was how it was a known problem that certain countries (for illustrative purposes, yes, China was one of them) do not innovate as well as others, so they have a tendency to reverse engineer other products or get designs from other countries by any means who have already done the innovation. </span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">Now in an outsourcing model, a firm has already done the hard yakka on innovating - they just need to find a firm who can produce the good or service as cheaply as possible. However, if a firm is willing to steal those innovations from a competitor and beat them to the market, that has the potential to kill your competition. Money wasted on R&D that they were hoping to reclaim on future sales that will now never happen.</span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">What the first article is referring to is China's willingness to promote itself as a superpower and gain advantage through every means, by basically stealing IP, economically crippling their competitors all without firing a single shot. Or taking your enemy out pre-emptively if you wanted.</span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">The second article suggests that culturally they face significant challenges with defending their home systems. For example, the lack of peer review for their software leaves it potentially wide open to bugs. Equally, reporting them can create a loss of face (in more ways than one).</span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">This just got me thinking - what if this means that China's actions on offense are due to the realisation they have defensive issues that aren't going away anytime soon? What if this means they were on the offense because it just made more sense - its a lot easier to kick in someone else's door than it is to guard your own? Especially if you know that in doing so you're depriving resources away (from an already taxed and resource starved adversary) that might normally be spent attacking you.</span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">Again, I don't want this to degenerate into an Anti-China post - that's certainly not the point. It is meant to be a discussion signalling a shift in cyber security strategy. Is it possible for nation states, even corporations, to eventually move away from a defensive strategy and rely purely on offensive techniques since they will yield more fruit (albeit at greater risk)?</span><br />
<br />
<span style="font-family: Arial,Helvetica,sans-serif; font-size: small;">The US - and many other countries - are more than aware that their cybersecurity capabilities are thin at best. Would it not be in everyone's best interests, to then switch to an offensive approach when you consider that the results of such an approach would yield a higher degree of success?</span><br />
<div style="font-family: Arial,Helvetica,sans-serif;"><br />
</div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">I haven't put too much thought into this, but I am curious what others might think on this.</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;"><br />
</span></div><div style="font-family: Arial,Helvetica,sans-serif;"><span style="font-size: small;">- J.</span></div><span style="font-family: Arial,Helvetica,sans-serif; font-size: small;"> </span>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-23995375990567283052011-04-17T14:23:00.000+10:002011-04-17T14:23:53.283+10:00Advanced Persistent NonsenseLately the threat posed by APT has gained a lot of attention. As highlighted by my April Fool's Day post, there was the RSA incident, the HBGary incident (which was more "Persistent" than anything else), the Australian PM's laptop getting owned (which barely got more than a day's press), and more.<br />
<br />
I wanted to really try and summarise what APT is and what is the real takeaway message for people out there.<br />
<br />
<b>Advanced Persistent Threats always have been there.</b><br />
Always. Without exception. You may not have known them by this name. You may never have heard of it before. That doesn't mean these attacks weren't going on before. The point being, they are not new. The idea that people have never been hit by a highly skilled, motivated attack who was never going to stop until he gained access to your network and got what he wanted is insane.<br />
<br />
Sure, the label is popular when talking about state actors, but it is incorrect to assume that if the attacker isn't state sponsored or backed, that it isn't APT. That's not to say that are not in some cases either....<br />
<br />
In anycase, the point is, these kind of attackers have been around since the dawn of the Internet.<br />
<br />
<b>You cannot stop APTs</b><br />
To quote one of the <a href="http://vrt-blog.snort.org/2010/03/apt-should-your-panties-be-in-bunch-and.html">Sourcefire VRT </a>guys, Matt Olney, in what is probably the best definition of APT I've ever seen: <br />
<br />
<i> "There are people smarter than you, they have more resources than you, and they are coming for you. Good luck with that."</i><br />
<br />
Firstly<i>, </i>we need to really revisit what we know of information security. If there's anything we've learned to date, it is that nothing can be made 100% secure. The best result one can seek is to delay, defer or hinder an attacker to otherwise induce them into targeting an easier target. If we accept that as an axiom, then we can further conclude that if the attacker is only after you, then you're pretty much screwed given sufficient time and skill (or at least time enough to get skilled).<br />
<br />
Yeah, good luck with that indeed.<br />
<br />
<b>Most people are worried about the wrong thing</b><br />
Working in security - particularly consulting - you get to see a lot of different businesses and how they run and implement security. The sad reality is that most people do a poor job of it. I don't say that to insult anyone, it's just a simple statement of fact. Regardless of reason, too many business lack the basics controls. Too many people can be taken down by a script kiddie with a fresh copy of Metasploit. Too many people don't have a good handle on the basics, like <a href="http://jarrodloidl.blogspot.com/2010/03/wall-of-shame-patch-management.html">patch management</a>. Too many people still running around with IE6 as the default web browser. <br />
<br />
And yet they want to focus on APT?<br />
<br />
If you don't have down some basic processes - stuff like patch management, vulnerability management and proper logging and event management, if you don't pentest your environment hollistically as well as individual projects from internal AND external threats, then there's really no point. You need to learn to walk before you run.<br />
<br />
Also, in understanding APT we're talking about a hacker doomsday scenario where you are going to get owned and there is very little (if anything) you can do to stop it. In most cases, the best you can ever hope for is a shot at detecting the attack in progress. This is what RSA and Google were able to do. And how do you think they did it? Uhuh that's right. See above. This is why I laugh at people bagging these businesses getting owned. Everyone can get owned. But when the shit hits the fan how they deal and respond is key. The fact they could detect these attacks gives an indication of their level of security maturity. Could you say the same about your business? Uhuh, I didn't think so.<br />
<br />
So in conclusion - let's get real with the problems we can solve. Don't worry about the hacker doomsday scenario that you cannot prevent. Focus on getting the basics down first. Once you get a handle on those processes, then we can have a chat about APT.<br />
<br />
PS: You'll still get pwn3d though.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com2tag:blogger.com,1999:blog-5388115022531534533.post-41287389313992053202011-04-01T07:31:00.002+11:002011-04-01T13:23:04.653+11:00I give up<div class="ii gt" id=":18m"><div id=":18l"><div class="MsoNormal">A number of events in past months have forced me to reconsider my position on a number of issues.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Foremost in my mind:</div><ul><li><a href="http://jarrodloidl.blogspot.com/2011/01/vodafone-privacy-scandal.html" target="_blank">The Vodafone scandal in Australia</a>, </li>
<li><a href="http://news.theage.com.au/breaking-news-technology/australian-pms-computer-hacked-report-20110330-1ceyf.html" target="_blank">the Australian Prime Minister’s Laptop being hacked</a>, <br />
</li>
<li>Office of National Assessment’s of Govt security (<a href="http://www.itnews.com.au/News/249248,nsw-agencies-pass-it-security-test.aspx" target="_blank">and SQL injection being described as “non-major”</a>), </li>
<li><a href="http://www.rsa.com/node.aspx?id=3872" target="_blank">RSA being owned</a>, <br />
</li>
<li><a href="http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html" target="_blank">the Comodo CA hack</a>.</li>
</ul><div class="MsoNormal"><br />
</div><div class="MsoNormal">What do these all highlight:</div><div class="MsoNormal">- Ultimately, the blatant disregard that Australian citizens have towards their own privacy,</div><div class="MsoNormal">- Similar disregard by our government to protect its information assets,</div><div class="MsoNormal">- Gross misunderstanding over what SQL injection means (in spite of seeing <a href="http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars" target="_blank">the ownage of HBGary</a>),</div><div class="MsoNormal">- The fundamentally flawed architecture we come to rely on (SSL & CAs) .</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">We (Australia) have no mandatory notification of breaches, no penalties for privacy breaches, weak government interest, capability and skill in securing our own assets. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I am tired of banging my head on a wall and hoping that things will get better and that I can play any role in that future. I have <a href="http://jarrodloidl.blogspot.com/2011/02/economic-benefit-build-vs-break.html" target="_blank">blogged about it in the past </a>and I hoped this was just a phase and I’d get past it. But I can’t and I’m over it.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">A wise man once said to “follow your bliss”. Once upon a time, I loved pillaging boxes and finding holes. Somewhere along the way, I lost my path. I betrayed my own values. I got a set of programming books piling up in my library I’ve never touched because I’ve been so focused on architecture, strategy and business. None of this makes a lick of difference in the scheme of things and quite frankly, if the Australian population and our own government don’t give a shit, I frankly don’t see why I should. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Sure I believe you can focus on architecture, sound decisions based on risk and intelligent approach to understanding your business and uplift your security. But at the end of the day, its a drop in the bucket. When people think SQL injection doesn’t mean much and lazy administrators can’t be stuffed patching Windows boxes because it involves work (err... “downtime”), then nothing I do will ever really matter. Whats more, nobody seems intent in addressing these problems. There is no patch for human stupidity (or laziness for that matter).</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">So I’ve decided to “follow my bliss”. I will be focusing on penetration testing, vulnerability research and programming solely from now on. I will get back to my roots – and I am the first to admit I have a lot of things to catch up on. But I will enjoy the journey at least. I will devote myself to finding the holes. Let the fixing go to other people who have the stamina and the patience to do it – I’m done with it.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">To the pentesters I’ve hassled – you guys were right all along. I was wrong. </div><div class="MsoNormal" style="color: #cccccc;">To the people who supported me – sorry guys, but I’ve seen the light. </div><div class="MsoNormal" style="background-color: black; color: #cccccc;"><br />
</div><div class="MsoNormal" style="background-color: black; color: #cccccc;">Sorry y’all.</div><div class="MsoNormal" style="background-color: black; color: #cccccc;"><br />
</div><div style="background-color: black; color: #cccccc;"> </div><div class="MsoNormal"><div>- J.</div><div><br />
</div>UPDATE: For those who missed the date of the post, yep I'm pulling your leg. Happy April Fools Day y'all. </div></div></div>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-52559996984848016822011-03-16T20:29:00.000+11:002011-03-17T11:04:34.545+11:00I love WAFs and so should you.<i><b>Warning: I work for Dimension Data and we're a known reseller of Web Application Firewalls. If you think that alters my opinion on this subject, then I suggest you stop reading.</b></i><br />
<i><b><br />
</b></i>Lately I've seen some hatred thrown towards Web Application Firewalls. Some of it I think is misguided, some of it misunderstood. However - and perhaps more disturbingly - a great deal of it just strikes me as wrong. I am of the belief that much of the antipathy thrown towards these things comes from people who have not worked in enterprise environments where application development is a common part of IT. This means there are a lot of assumptions on the degree of difficulty in either patching an enterprise application or the speed in which a hotfix can be applied. This post is aimed at reviewing those assumptions and clearly separating fact from fiction.<br />
<br />
Firstly, I would encourage everyone to read <a href="http://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls" target="_blank">OWASP's Best Practise Guide: Use of Web Application Firewalls</a> to ensure we're on an even understanding. This is a really good read and I think gives anyone with even a foundational understanding of web application security a good overview of their strengths and limitations.<br />
<i><br />
</i>One of the constant criticisms against WAFs is that they are essentially a blacklist model which applies pattern matching based on a known vulnerability ("known bad") which is always putting the defender on the back foot. Further criticisms highlight that the time spent configuring the WAF for that bug could be better spent fixing the application. I might have missed some so if I have, please fire away.<br />
<br />
To draw this conclusion you would would have to be operating under a number of assumptions (so I'm taking a bit of a punt here, based on conversations I've had or my take on what these people are thinking - feel free to clarify if you think I'm mistaken):<br />
<br />
<ol><li>It is equally as quick to apply a fix to an application as it is a WAF</li>
<li>The cost in time in implementing a hotfix on a WAF is equal to that of fixing the original defect in the code.<br />
</li>
<li>Applying a hotfix in a WAF and the code is "the same thing."</li>
</ol>Now going back to the above link:<br />
<div style="text-align: center;"><i>"The main aim in using a WAF is therefore securing the existing, often productive web applications, where the required changes within the application can no longer be implemented or can only be implemented with a disproportionately large amount of work. This applies to vulnerabilities in particular which have been revealed via a penetration test or even via analysis of the source code, , and - <u>e</u></i><i><u>specially in the short term -</u> cannot be fixed within the application."</i></div><br />
The emphasis above highlights the fundamental aim of the WAF I want to drill into everyone's head. They primarily exist to as a temporary solution until the code can be fixed. That's it. Nothing more, nothing less.<br />
<br />
Now to challenge the above assumptions -<br />
<br />
<i>1) Code changes are NOT always quick and easy to push through to Production.</i><br />
<br />
If you disagree, then I KNOW you've never had to deal with developers, QAT, change control or project managers and navigate any number of hurdles that impact with a code release (especially during crunch time). Now I am the first to admit that what follows are some bullshit issues. Nonetheless, they are REAL issues and if you want to improve security within enterprise applications then you need to realise that these questions will come up:<br />
<ul><li>Is there a project code for the application developers and testers to charge their time against? </li>
<li>Does your hotfix take developers away from working on mission critical functionality for a given project?</li>
<li>Once the fix is applied who is doing the retesting and will the re-test delay the release to Production? </li>
<li>If you plan on cutting corners (regression testing is usually the first victim) because of the "urgency" or you "believe it won't impact the rest of the code" to get your hotfix into Production, who is accepting the risk?</li>
<li>What is the review period for all change requests to Production assets?</li>
<li>Is there a change embargo in place at present?</li>
</ul>You have to understand that if a code change leads to a defect in existing functionality, you (as the "security guy") will cop the blame - not the developers. So it really is in your best interests to NOT cut corners on any of this. <br />
<br />
Having said that, let's presume for a moment that you do not have to deal with any of these issues and I'm horribly, horribly wrong. That's fantastic for you, but we also have to consider the fact you work in an environment that does not even pay lip service to ITIL, COBIT or any number of best practise frameworks with regards to the management of IT infrastructure. This means you have no assurances at ALL that unauthorised code changes haven't taken place already.<br />
<br />
Or put more simply, you probably have far bigger problems to worry about.<br />
<br />
<i>2) Time spent on patching an application is NOT equal to configuring a WAF.</i><br />
<i><br />
</i>For starters there are simply less people involved. Typically you have the business owner for the application in question, maybe an engineer in Networks as well as Security Operations to conduct the change and some Change Management folk to review the whole thing. Infact, I've seen this done in enterprise environments with less than 4 folks involved. Notice how there are no development staff and application testers involved? If you assume you would normally have another two people involved from each of those teams minus the Network engineer. That's being very generous too. Normally the process can take much longer (see point 1) and involve many more people. This means that applying a fix at the WAF could (taking the above example), reduce the cost of fixing by 20% or in large cases, as much as 75%. You can also argue security fixes can be applied as Emergency changes, vastly reducing the time window from the change being raised to being implemented. Time to test and implement? Much quicker. <br />
<br />
In practise too, what will happen is that you will more than likely bundle up multiple bug fixes and roll them out into a single release. This means that the testing cycle is much longer, as is the release and the actual cost. God forbid the defect is significant enough to warrant a major re-write of the entire code base. You can then take the above numbers I've given them and throw them out the door. You're then in a position where you are still going to have to prioritise your time and effort and in all probability, you'll run with a WAF rule in the short run because the prospect of leaving that application without any form of defence in the until the code itself is fixed is something neither you or the business owner is wanting to chance. <br />
<br />
This leads to my next point.<br />
<br />
<i>3) Applying a hotfix on the WAF buys you time (if you're lucky). <u>It does not solve the problem.</u></i><br />
<br />
Does this mean you are better off applying hotfixes in the WAF than in the application? God no. You need to fix the root cause which is inherent in the application. But if we can accept we can get a temporary fix into Production on a WAF quicker than we can by applying a hotfix, then the use of a WAF becomes much more palatable. It is an acceptance that you are <u>buying time</u> for your application, <b>not </b>solving the problem. <br />
<br />
If a virus somehow takes spread on a network what do you do? Normally you would have desktops in segmented zones to contain the spread. In essence, you are using the firewalls to contain it. This buys you time until you can determine the root cause and remediate. WAFs are no different - implementing a change on these appliances <i>buys time</i> for the defenders to fix the root cause. <br />
<br />
We block ports because we don't want people accessing applications carte blanche. We accept that there is some network traffic we do not want. Why is it so hard to apply the same logic to our applications? Nobody refutes the fact that the root cause of a vulnerability must be fixed (unless they have rocks in their head). But we live in a world where not everything is black and white and fixing problems is infinitely more complex than finding them. This where the entire concept of "defense in depth" has arisen - the knowledge that we build in layered to defences to prevent, mitigate or slow down an attacker from compromising an application or system. <br />
<br />
To not accept that a WAF plays a valid role in a defensive strategy is to not only deride the entire notion of a "defense in depth" strategy, but it also devalues the role of other security technologies we use every day. Everyone in infosec sneers at the notion when someone says "we have firewalls so we are safe" because we know that is false. But no-one in the field in their right mind would call the technology useless. Nobody in their right mind would call airbags alone useless but we'd certainly recognise their value in road safety when combined with other safety mechanisms within a car - e.g. brakes, seat belts, etc. <br />
<br />
Additionally, if one is in a position whereby your application is a black box (where you essentially have no access to the code) then the WAF might be one of the few defensive mitigation strategies at your disposal. Does that mean you should leave an application you cannot patch or secure long term in your network? Ideally not. It certainly beggars the question how you found yourself in this situation in the first place - i.e. why is this not covered under your support/maintenance contract? And it does happen - typically with large common off the shelf (COTS) applications but in such an instance, your long term strategy might be to migrate away from that vendor and product so you can get rid of it entirely. In which case, the use of a WAF is still a perfectly viable strategy since fixing the code base isn't an option. Ultimately this is arguably the worst case scenario one can find yourself in too.<br />
<br />
Sure - one could build an argument that if you were to build a secure box and application out of the gate with no unnecessary services and plug it into the Interweb it would hold up. I could also assume no new attacks will ever be developed, no vulnerabilities will ever be found in that environment ever again and that Palestine and Israel will come to a peace agreement in the next 12 months. In all practicality, there are some things we have to accept aren't going to happen in a hurry no matter how much we'd like them to and we work with what we've got. <br />
<br />
Anyway, here's something to think about for the anti-WAF zealots out there.<br />
<br />
Cheers<br />
<span style="color: #888888;"> </span>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com1tag:blogger.com,1999:blog-5388115022531534533.post-63640980951117554652011-02-17T20:46:00.000+11:002011-02-17T23:45:28.805+11:00Economic benefit: Build vs BreakI have one friend who I swear, is trying to inflame me with my whole build vs break rhetoric. He knows who he is, so this post is for him.<br />
<br />
Recently events in the news, finishing economics, and some other personal events has fired me up enough to forego my original post on WAFs (for now) and discuss some economic basics again. Mostly some random idea I have been toying with, applying some economic theory to common problems. I don't know if this will solve anything - some of these ideas are very much in their infancy but perhaps by putting it out there, someone else might take the ball and run with it.<br />
<br />
Basically, the economics of security are stuffed. I don't mean just "slightly broken" - I mean completely, utterly and currently, irrevocably stuffed. To try and phrase it as an economist might, the marginal cost of fixing software exceeds the marginal benefit - no matter which way you slice it or dice it. I know this isn't revolutionary - David Rice in his book "<a href="http://www.geekonomicsbook.com/" target="_blank">Geekonomics</a>" covered it pretty good (apparently - I haven't read it in its entirety yet). But from what I can tell, "building" (as I refer to it) is dead.<br />
<br />
Yes that's right. Building is dying. <br />
<br />
I've been asked (as recently as today even) whether I think its dying. I always say that same - no it never will. I have always maintained that. But I guess I've been a lot my critical of my work lately and what I can do to improve what I do. <br />
I think it has been for a long, long time but none of us really paid any attention. <br />
<br />
I'll try to illustrate with some examples:<br />
<br />
On one side of the fence, black hats make uber money and get off with slap on the wrists:<br />
<a href="http://news.softpedia.com/news/Russian-Hacker-Pleads-Guilty-in-RBS-WorldPay-10-Million-Cyberheist-Case-183007.shtml" target="_blank">http://news.softpedia.com/<wbr></wbr>news/Russian-Hacker-Pleads-<wbr></wbr>Guilty-in-RBS-WorldPay-10-<wbr></wbr>Million-Cyberheist-Case-<wbr></wbr>183007.shtml</a><br />
<br />
This is one fraudster perpetuated a $10million USD heist, on a scale unprecidented in human history - 280 cities, 2,100 ATMs, all within 12 hours. His punishment? 2 years suspended sentence.<br />
<br />
Entire towns loaded with cyber criminals driving Mercs:<br />
<a href="http://www.wired.com/magazine/2011/01/ff_hackerville_romania/" target="_blank">http://www.wired.com/magazine/<wbr></wbr>2011/01/ff_hackerville_<wbr></wbr>romania/</a><br />
The cops themselves acknowledge:<br />
<i> “You arrest two of them and 20 new ones take their place,” he said. “We are two police officers, and they are 2,000.”</i><br />
Of course, it doesn't stop there. It's now being reported that fake AV companies can make more profit than legit ones<br />
<a href="http://www.infosecurity-magazine.com/view/16010/rsa-fake-av-companies-making-more-money-than-security-vendors/?utm_source=twitterfeed&utm_medium=twitter">http://www.infosecurity-magazine.com/view/16010/rsa-fake-av-companies-making-more-money-than-security-vendors/?utm_source=twitterfeed&utm_medium=twitter</a><br />
<br />
If you don't want to move into fraud - no problem. There's a huge black market for vulnerabilities, databases, malware, botnets, pwn3d hosts, etc. You name it. Just leave the moral conundrum at home, do your work, enjoy the craft and don't ask questions about who pays for your warez.<br />
<br />
On the other we have <a href="http://www.blackhat.com/">conference </a>after <a href="http://www.defcon.org/">conference </a>after <a href="http://www.shmoocon.org/">conference</a>, celebrating security researchers whose primary objective is to break all security that is created. It used to be that the idea of breaking stuff was to find ways to innovate and make it better. Somewhere along the way that all got lost. How many good conferences are there where interesting ideas about building and creating are there? I can think of only <a href="http://www.cosac.net/">one </a>and its largely unsung to the best of my knowledge (yet looking at the lineup of some of the speakers you know there are some legends in attendence). Is it no wonder <a href="http://lcamtuf.blogspot.com/2011/02/world-of-hbgary.html">we are making no progress</a>?<br />
<br />
If you want to make money building, you're options are to open to the public (Open Source) be a pauper but get some recognition. Unless you are willing to build a product and sell it, commoditise it (WAFs, firewalls, etc) it just becomes Yet Another Product, which creates its own issues. If you want to make money however, there's plenty to be made. Just look at <a href="http://www.mozilla.org/security/bug-bounty.html">Mozilla</a>, <a href="http://www.zerodayinitiative.com/">ZDI</a>, <a href="http://labs.idefense.com/">IDefence</a>, and so one. They'll all pay you to find the holes. <br />
<br />
But you know what - let's assume that you dismiss all that, you decide to build stuff just for the love of it all. Really, whats the point? <a href="http://www.cio.com.au/article/376889/mixed_findings_privacy_commissioner_vodafone_report/">Take a look at the tragedy that is the NSW Privacy Commissioner's findings into Vodafone</a>. They don't even really take action, even when its proven that a company acted negligently. Economically, you can applaud Vodafone's actions. They took the cheapest, lamest, most pathetic way out (changing passwords every 24 hours). Forget VPNs, forget two factor authentication. They did it El Cheapo and the Privacy Commissioner said "yep, good enough." As security professionals this is an utter disgrace and our own efforts as an industry are actively undermined by government.<br />
<br />
Unless the incentives are reversed, unless companies are finded for insecure software, vulnerability researchers then actively rewarded for finding bugs using the taxes collected from vendors, then the driver to innovate, improve and truly create will never really happen. This would disincentivise firms into producing bug ridden software, entice legitimate security research and spur more spending to areas where it is truly needed - better APIs, better education, better business practises and processes, etc.<br />
<br />
But, until that day comes, you are economically better off breaking. That's just a fact. You will probably have more fun. You will make more money. Get more recognition if that's what you want and worst case scenario, if you find yourself lining up for unemployment, you know that you'll never go hungry. Ever. Unless an asteroid hits earth, destroys the Internet and sends us all hurtling back to the Dark Ages but if that happens we have bigger fish to fry.<br />
<br />
- J.<br />
<br />
EDIT: As a postscript to this, I remember when I used to work in Network Abuse, there was a story from one of my team mates who was chatting with one of the big time spammers at the time as they had infiltrated some of their private forums. My team mate asked the spammer over chat one time "aren't you afraid of going to jail?" The guy replied "I am 21 years old, I have $2 million in cash, in garbage bags, buried where no-one will find it. Even if I go to jail, I'll serve a minimum of two years in jail in a white collar resort. I'll then get out maybe in 6 months with good behaviour, move to Mexico and retire." This is stretching back a bit now, but the principle still applies.<br />
<br />
His (the spammer's) point was that the laws were not sufficiently harsh to punish his crimes that it was worth the time to do the crime. Comparing it to modern day fraudsters, we're at the same point. If you get caught in a Western country, you'll do big time. But more to some country in the Balkans, Russia, Romania and chances are, given the levels of corruption and organised crime, you'll probably be fine.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com3tag:blogger.com,1999:blog-5388115022531534533.post-25119252857902752952011-02-01T23:33:00.000+11:002011-02-02T21:08:29.852+11:00Why IT must be run as a business<div class="MsoNormal"></div><div class="MsoNormal">I recently read <a href="http://taosecurity.blogspot.com/2011/01/it-as-business-train-wreck.html">this </a>blog post on Richard Bejtlich's blog (and I am a bit behind the times) but it really rubbed me the wrong way. I am probably misinterpreting the point of the post but the way I read it, Richard was just pointing out that there were some salient points. I guess that I read the points that he highlighted and found that they were either people squabbling over semantics or they were IT nerds that had been promoted to management roles and somehow thought that they were unique, beautiful snowflakes and were different or more important than any other business function.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">How is IT any more "special" than say marketing, sales, finance, etc? They aren't. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I want to believe that the aim of the article was to say that IT should seek to be a trusted advisor to the business and serve the meet those ends, but it really read to me like IT should be able to dictate terms to the business and demand what they want. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Now I've worked in some places with IT departments that have been described as an "<a href="http://www.securitysoup.com/?p=33">post apocalyptic backwards IT environment</a>". And those places were paradise compared to some of the hell holes I've seen since. And the worst ones I have ever seen are those that locked into this mindset that they can dictate how/what/why/when and where the business can do what it wants. They dictate what laptops they can use, what applications they can use and so on and so on. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Now don't get more wrong, I understand the reasons why this is necessary to some extent: ensuring standardised operating environment, maximising pricing benefits, maximising process efficiency and so forth. But seriously, if IT is going to be the lynch pin to the business, then dictating terms is the <i>worst </i>thing you can do.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">C-level executives are keen to reduce cost and focus on numbers not for the sole purpose of "looking good" to the board or shareholders. They know that but reducing their marginal cost of production, they are able to produce goods at a lower opportunity cost than their competitors. This means that potentially they are able to put their competitors out of business just on pricing alone. And this is simply <i>one </i>tactic can use to crush competition. So any CIO looking to gain efficiency is going to look at reducing the size, complexity and operational overhead of their IT infrastructure, applications and staffing where ever they can. I know I would. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I remember meeting one client ages ago who is quite well known for reducing their IT size to an almost infinitesimally small size. At the time I met this client I thought the concept was in itself, appalling. After knowing what I know now, going through my degree, I'm convinced this guy is actually a visionary. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">These goals are a primary driver behind the booming enterprise architecture industry which seeks to bridge IT and business by optimising business process through efficient, robust, scalable and re-usable architectures. Any CIO or IT manager worth his weight who is not seeking to optimise and consolidate and cannot rationalise the cost benefits of doing so, is doing his company a disservice. For every IT manager that fights to retain infrastructure in-house, even when it is more expensive in doing so is also harming the longevity in the company by forcing them to spend money on an area that isn't a core competency.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">And for all the bitching in this article that IT isn't focusing on innovation, I will tell you this: For every dollar your company spends retaining and managing IT assets, that is one less dollar your company is spent doing really cool, innovative, exciting stuff that is core to your brand. And for every dollar you spend maintaining something that isn't core to what you do, that's potentially a dollar that your competitor is gaining on you. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Now before I'm stoned to death by my infosec peers, I'd argue that our role is to acknowledge that progressive, forward thinkers are out there and we need to acknowledge that stopping the move to cloud based technologies (IaaS, SaaS, etc), outsourcing, etc, is comparable behaviour to people throwing sabots into textile looms back in the 15th century for fear of losing their jobs to automation. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Are we as an industry <i>really </i>that unevolved and immature?!? Why can't we look at our methods for ensuring that information assets are adequately secured as part of the migration, that they are managed appropriately and in the even they simply can't, that mitigating controls are applied as best as possible and residual risks are understood by all so there is no misunderstanding?</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">I understand that internal chargebacks are not popular and I understand the argument about the chilling effect it can have, but simply put, this is good economics. It simply proves the point that the business is wasting money on a service that it can get from a third party provider for less (that is of course assuming that the business is comparing apples with apples and not say, a fully redundant SAN storage with a USB hard drive from Dick Smith).</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">If IT really want to talk innovation and do really cool, exciting stuff, look at how you can get rid of those crappy legacy applications in your environment that are unpatched and unmanaged. Look at sloppy, inefficient business processes and see how you can improve communication, consolidate storage and better facilitate excellent customer service. The cost savings are a secondary benefit and should be obvious in the face of such synnergies.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">As security folks we have the potential to be the glue in these discussions, looking at ways we can protect the business. We can ensure that developers build applications using robust <a href="http://www.owasp.org/images/d/df/OpenSAMM.pdf">methodologies </a>and <a href="http://www.owasp.org/index.php/OWASP_Guide_Project">guides</a>, leverage <a href="http://www.owasp.org/index.php/ESAPI">APIs</a>, etc. We can ensure provisions are included into contracts to enforce minimum standards of security, even influence choices of vendor and/or pricing. We have a lot more to offer the business than we often realise but it really does come down to the approach. In that respect, I think the article hit the money.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Unfortunately working in infosec is not glamorous and we get saddled doing our jobs, working with <a href="http://www.networkworld.com/news/2011/013011-shmoocon-2011-the-macgyver.html?source=nww_rss">what we have</a> rather than what we'd like to. This to me is what it is really about - making better use of what we have and looking at how we can help the business rather than hinder it.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In the future, businesses are not going to have monolithic IT shops. The future is going to involved outsourcing on a scale that you or I today can hardly conceive of. Enterprises will have all their applications, infrastructure, development - all outsourced. Other core functions will also become increasingly outsourced (I've already seen this). This enables businesses to become increasingly agile and better focus on their core competencies. IT will become more ubiquitous and pervasive than we can conceive today. Information will fly around in so many directions across so many devices that our very notions of privacy and security will be constantly redefined based on an threat landscape that will beggar belief. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Our role in this world as security professionals will be to constantly adapt and redefine these notions on the basis of the information exchanges needed by business and perhaps more importantly, the speed in which we can do it. The world is not perfect and neither is information security in practise. But if we can help businesses make informed decision of risk, then our work is not in vain.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">- J.</div>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com8tag:blogger.com,1999:blog-5388115022531534533.post-41270935220341692732011-01-28T20:54:00.000+11:002011-01-31T22:56:04.436+11:00Is D-Link.com.au serving up malware drivers?Hi guys,<br />
<br />
D-Link have firmware drivers on their website, specifically the DSL-502T and DSL-504T that are showing as malware when I upload them to Virus Total to confirm.<br />
<br />
Here is the 502T:<br />
<a href="http://www.dlink.com.au/tech/Download/download.aspx?product=DSL-502T&revision=REV_A&filetype=Firmware">http://www.dlink.com.au/tech/Download/download.aspx?product=DSL-502T&revision=REV_A&filetype=Firmware</a><br />
<br />
Here is the 504T:<br />
<a href="http://www.dlink.com.au/tech/Download/download.aspx?product=DSL-504T&revision=REV_A&filetype=Firmware">http://www.dlink.com.au/tech/Download/download.aspx?product=DSL-504T&revision=REV_A&filetype=Firmware</a><br />
<br />
<br />
(Be sure to download the EXE and extract it).<br />
<br />
I freely admit I have not tested these drivers out in a test environment (e.g. VM running procmon, or tried reversing them). But the reports from Virus Total are not thrilling:<br />
<br />
502T driver report from Virus Total (17/43 vendors):<br />
<a href="http://www.virustotal.com/file-scan/report.html?id=72c73d9726f1b6ce626b26ea8086336bdbc1a4fad210b11d977a65542a38b007-1296117635" target="_blank">http://www.virustotal.com/<wbr></wbr>file-scan/report.html?id=<wbr></wbr>72c73d9726f1b6ce626b26ea808633<wbr></wbr>6bdbc1a4fad210b11d977a65542a38<wbr></wbr>b007-1296117635</a> <br />
<br />
504T driver also reported infected with 20/43 known A/V products this time:<br />
<a href="http://www.virustotal.com/file-scan/report.html?id=80943a9cfd200e66430a54e1b42d6d962a4f0d78c3c558334d4760c3576eff11-1296187981" target="_blank">http://www.virustotal.com/<wbr></wbr>file-scan/report.html?id=<wbr></wbr>80943a9cfd200e66430a54e1b42d6d<wbr></wbr>962a4f0d78c3c558334d4760c3576e<wbr></wbr>ff11-1296187981</a><br />
<br />
The 504T sample was also reported on Virus Total back in August 2010 (I have no idea if it made its way back to D-Link though):<br />
<a href="http://www.virustotal.com/file-scan/report.html?id=80943a9cfd200e66430a54e1b42d6d962a4f0d78c3c558334d4760c3576eff11-1283127150" target="_blank">http://www.virustotal.com/<wbr></wbr>file-scan/report.html?id=<wbr></wbr>80943a9cfd200e66430a54e1b42d6d<wbr></wbr>962a4f0d78c3c558334d4760c3576e<wbr></wbr>ff11-1283127150</a><br />
<br />
<br />
Not just tiny vendors either: McAfee, Fortinet, Avast, AVG, VIPRE. Email from the technical support team has referred to them as "no name brands" as well. Very professional guys.<br />
<br />
Why I am posting this here? Because I'd like independent testing (ok, I'll be honest - I lack a Windows VM to test).<br />
<br />
<br />
I've also tried emailing and phoning D-Link technical support since Australia Day. I've been told on three occasions that the Anti Virus software attempting to stop me from installing is "normal" and I should "disable my A/V". I gave them all the steps needed to replicate the fault, asked what processes/checks they made to ensure that the drivers on the site have not been compromised. D-Link told me that this has been raised with their "Technical Support Manager". Despite a full business day... no response.<br />
<br />
Funny, I would have thought someone reporting that your website might well be owned would be serious and warrant a more thorough investigation. <br />
<br />
Oh well, I'll just put this out in the public eye and see what other people find.<br />
<br />
Please note, I am <u><b>not </b></u>saying that the drivers on the site have been compromised as I cannot say that for certain.<br />
<br />
What I am saying however is two files are reporting as malware with a SIGNIFICANT number of anti virus vendors and bears further investigation. When it has been raised with D-Link they seem highly disinterested in pursuing it further.<br />
<br />
If anyone wants to take a further look, please post your findings here as I'd be very interested. <br />
<br />
Thanks,<br />
<br />
- J.<br />
<br />
EDIT:<br />
* Double thanks to <a href="http://twitter.com/#%21/jcanto">Julio Canto</a> & <a href="http://twitter.com/#%21/uglypackets">@Uglypackets</a> for actually doing the real digging that I should have done. Julio has <a href="http://twitter.com/#%21/jcanto/status/31336282885980160">confirmed</a> with several AV vendors that this isn't malware. I guess its safe to call this a day. All the same the whole situation has certainly raised a lot more questions in my mind about how D-Link manage their security:<br />
<br />
<ul><li>Why would you not escalate potential security quesitons? </li>
<li>Why would you not answer questions about checking that the hash values on the fileserver repository haven't changed? </li>
<li>Why would you tell your clients to disable A/V?</li>
<li>Why would they not want to work with well known A/V vendors to eliminate false positives on their products?</li>
</ul>Anyway, thanks guys. I freely admit reversing is not my forte and as much as I want to get into it (got Eldad Elam's book in my bedroom right now sadly enough) there is no time for me these days. <br />
<br />
* Props to GPLama for his suggestion that I run this through Threatexpert.com. Their analysis can be found here and they confirm both samples as malware as well:<br />
<br />
DSL-502T:<a class="cssButton" href="javascript:void(0)" id="publishButton" onclick="if (this.className.indexOf("ubtn-disabled") == -1) {var e = document['postingForm'].publish;(e.length) ? e[0].click() : e.click(); if (window.event) window.event.cancelBubble = true; return false;}" target=""><div class="cssButtonOuter"><div class="cssButtonMiddle"><div class="cssButtonInner">Publish Post</div></div></div></a><br />
<a href="http://www.threatexpert.com/report.aspx?md5=36f54bb39f8dc1464f743045eeadd0b6">http://www.threatexpert.com/report.aspx?md5=36f54bb39f8dc1464f743045eeadd0b6</a><br />
<br />
DSL-504T:<br />
<a href="http://www.threatexpert.com/report.aspx?md5=2cb3247fae790f79960bc1780cc39e97">http://www.threatexpert.com/report.aspx?md5=2cb3247fae790f79960bc1780cc39e97</a>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com9tag:blogger.com,1999:blog-5388115022531534533.post-63153294202923263092011-01-26T09:28:00.000+11:002011-01-26T21:43:26.170+11:00Architect vs Consultant vs Penetration Tester<div class="MsoNormal">Now there seems to be a bit of twitter rage at the moment around pentesting and consulting and what it should be or even what it should represent. I made a bit of an off the cuff comment that pentesting is a conversation opener and Twitter only supporting a 140 character limit, I didn't bother to clarify my stance.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">See below a copy of the Open Software Assurance Maturity Model. I just picked this out to illustrate this discussion because I was reading it yesterday and I thought it would help make the point.<br />
<br />
<a href="http://www.owasp.org/images/thumb/7/71/SAMM-Overview.png/720px-SAMM-Overview.png"><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><img border="0" height="121" src="http://www.owasp.org/images/thumb/7/71/SAMM-Overview.png/720px-SAMM-Overview.png" style="margin-left: auto; margin-right: auto;" width="400" /></td></tr>
<tr><td class="tr-caption" style="text-align: center;">http://www.owasp.org/images/thumb/7/71/SAMM-Overview.png/720px-SAMM-Overview.png</td></tr>
</tbody></table><div class="separator" style="clear: both; text-align: center;"></div></a><br />
<br />
</div><div class="MsoNormal">I have commented in the past that penetration testing should be used as either a validation piece as I call it (or 'Verification' under OSAMM) or a discovery exercise (to find out what is unknown - e.g. a legacy application in your environment). Now far too much hate has been circling on what some people are saying about penetration testing and from my perspective I think its because none of us is really trying to see the other side of the argument and perhaps I've added fuel to the fire (sorry).</div><div class="MsoNormal"><br />
We all know that the skills of a penetration tester is incredibly deep as well as broad. This is so indisputable it requires little mention. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">However, the skillset required to break a network, or a system, or an application is a very, very different skill than fixing it and maintaining it. If you have ever worked in an enterprise environment for an extended period, you’ll know what I mean.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">To help make the point, I want to break down the roles of an architect, consultant and pentester into conceptual terms that in reality are grossly simplified (and kind of do an injustice) but for purposes of illustration will do for now (in at least as far as I see it):</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b>SECURITY ARCHITECT:</b></div><div class="MsoNormal">Architect thinks first and foremost conceptually. They focus on business requirements and how to align security to meet those objectives. This typically manifests in changes to IT (infrastructure, applications) but can just as easily be a process change if it is the simplest solution. Architects are able to dive town in depth on a technical level but generally speaking, not to the same degree as the other two.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b>SECURITY CONSULTANT:</b></div><div class="MsoNormal">Is the middle man between an architect and pentester. A consultant thinks in terms of risk. Usually a technical person who has moved into to consulting based on broader exposure to other areas of security or business and/or excellent communication skills to be able to articulate risk and translate architectural terms and concepts or low levels of detail that a penetration tester may unravel. The posess a moderate degree of technical skill generally, typically higher than an architect.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b>PENETRATION TESTER:</b></div><div class="MsoNormal">Highest degree of technical skill. Engineers often fall within this category too. They possess the deepest degree of knowledge and in many cases, the broadest. Their ability to focus on the microlevel of detail is the single greatest strength and in many cases their weakness.</div><div class="MsoNormal"> </div><div class="MsoNormal">Now if we look at the different phases within OSAMM, let us see where each role can fulfil:</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b>GOVERNANCE: </b>Architect</div><div class="MsoNormal"><b>CONSTRUCTION: </b>Architect/Consultant</div><div class="MsoNormal"><b>VERIFICATION: </b>Consultant/Penetration Tester</div><div class="MsoNormal"><b>DEPLOYMENT:</b> Penetration Tester</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">In a general sense, all three work in harmony to provide the coverage needed. I don't really know of a pentester that enjoys drawing up security policies but the truth is that the pentester's detail focus is what enables him to pick out an error in a line of code, or the desire to test a single form field for umpteen different ways to break weak validation. He has no interest to delve into the business processes required to secure the enterprise. That's what architects are good for. Conversely, Architects generally lack that sort of attention to detail to do the work of a pentester. They are conceptual thinkers ("big picture"). Consultants are good at going to all the design review meetings, arguing with the business over a security requirement they want to cut and explaining the consequences for that decision. A lot of pentesters really lack the articulation to be able to do this. Likewise, too many architects are accused of sitting in their "ivory towers" ignoring the realities of the world around them when difficult technical discussions need to be made.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Back to reality, the world is full of individuals and everyone brings a unique blend of skills to the table. Very few people can "do it all" really well. Some people can wear multiple hats. Some can do all three. In my experience those people have a depth of experience that only comes with time in this field. You cannot compete with raw experience.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">However because we all wear multiple hats, building a strong consulting practise relies on understanding the hats that everyone in your team has. When recruiting this often means looking beyond what you see before you and also seeing a bit of what can be. As a team, we are all more than the sum of our parts and our true value to our clients is leveraging our diversive skillsets to help uplift our client's security posture. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Being able to successfully implement a framework like OSAMM can only be achieved when all the members of a security team (or consultancy) work collaboratively. It takes time to build and maintain trust, understanding the client's business and making sure the work we deliver is truly strategic. Even if you're an in-house team it is every bit as important to take the time to understand the business rather than attempt to dictate terms. If you aren't having those discussions with your consultants (or with the business if you work in-house) and if there is no understanding of the business then something is wrong with the approach. Certainly it takes a certain level of degree of maturity to reach this point however, our roles as security professionals is to push to have these discussions and play in this space.</div><div class="MsoNormal"><br />
</div><div class="MsoNormal">A penetration test in and by itself is pointless if we are not having discussions with our client about their remediation activity, understanding their internal testing process, their security requirements and how they are being provided to developers, how is the architecture reviewed and ultimately, what is the level of engagement between the business and the in-house security teams. Having said that, a penetration test can also prove that all the strategic work you’ve done is still not up to scratch and needs improvement. In that respect, it might be used as an 'opener' or a 'finisher'. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">But there are three other business functions under OSAMM and multiple security practises that need to be achieved. Open frameworks like OSAMM prove that the skillsets used during each phase are specialist and require an entirely different focus. It is truly rare person to possess all the skills necessary to deliver each phase. It takes a certain level of self awareness to recognise what you can do and what you can't. Building a security practise around those skillsets requires embracing that diversity and ensuring people are given the opportunity to develop skills they might not otherwise have done as well as run with their strengths. </div><div class="MsoNormal"><br />
</div><div class="MsoNormal">However, ensuring the diversity of skills within a security practise and offering a wide variety of services that encompass all the business functions under frameworks like OSAMM requires that these other perspectives be acknowledged and developed. It is the only way to maintain our currency and relevance as our field evolves and develops. To quote Charles Darwin:</div><div class="MsoNormal"><br />
</div><div class="MsoNormal"><b><i>It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.</i></b></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">- J</div>Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com6tag:blogger.com,1999:blog-5388115022531534533.post-59163885851512325442011-01-22T00:37:00.000+11:002011-01-22T00:39:37.236+11:00What did we learn from the floods and fires?Years ago, I was lucky enough to be invited to closed session at Deloitte where Adele Melek (Global Leader of Information & Technology Risk Service) talked about one of their annual global security reports.<br />
<br />
One of the points in the report was about Business Contuinity Planning and Disaster Recovery. What was interesting was he made the very poignant observation that there was not a significant uptake of these consulting services when compared to other regions globally. I can't remember the exact numbers but he made a point that in late 2000/early 2001 a marginal percentage, lets say around 10% (I am throwing up arbitrary numbers which sound right from memory). Post 9/11, 12 months after, that figure skyrocketed to somewhere well above 90%. Watching those two towers go down and the number of businesses and lives affected, made a significant impact for businesses. He made a point - as have many others - it will take a 9/11 (or equivalent there of) for US before we start thinking of BCP/DR a little more.<br />
<br />
Well three years since I attended that session we've seen not one but TWO MAJOR tragedies I would argue would be our equivalent - the Victorian Bushfires of 2009 (aka. Black Saturday) and the Queensland Floods.<br />
<br />
Before anyone dismisses the impact of these in relation to 9/11, let me through up some numbers/stats:<br />
<br />
<b>Victorian Bushfires</b><br />
<ul><li>Destroyed 2,030 houses, 3,500+ structures in total<sup> </sup>and damaged thousands more. </li>
<li>The following townships utterly destroyed: Kinglake, Marysville, Narbethong, Strathewen and Flowerdale.<sup><a href="http://en.wikipedia.org/wiki/Black_Saturday_%282009%29#cite_note-Marysville-15" target="_blank"></a></sup></li>
<li>The fires affected 78 individual townships in total and displaced an </li>
<li>Displaced an estimated 7,562 people.</li>
<li>Total death toll: 178</li>
<li>The Black Saturday bushfires were the 8th deadliest singular bushfire/wildfire event in recorded history.</li>
</ul><br />
<b>Queensland Floods</b><br />
<ul><li>At least 70 towns affected to date.</li>
<li>Over 200,000 people were affected.</li>
<li>Damage initially was estimated at around A$1 billion.</li>
<li>The estimate of lost revenue from Australia's GDP is about A$30 billion.</li>
<li>Many state that the factual losses cannot be calculated but can be readily counted in the billions of dollars.</li>
<li>(These numbers could increase as of this time of posting btw).</li>
</ul>Even if your business or livelihood was not directly impacted by these events, chances are you had a business interruption as a result if you did business with anyone in these areas - or had friends and family who did. <br />
<br />
These incidents teach us that the <u>Availability </u>in information security goes beyond having data recovery and backup. It's about an understanding of your true assets - your buildings, your equipment, phones, desks, software, hardware and of course, your people. Sound business continuity planning relies on thinking in terms of business processes and functions (not just IT infrastructure) and absolutely defining what is critical and what isn't. What can you afford to run at a reduced capacity? Who are the key staff in your business and what happens if you lose them? How is knowledge transferred to prevent loss of critical corporate intellectual property? This isn't just useful in a crisis either. A lot of it just good corporate governance.<br />
<br />
Also, sound strategy here goes beyond thinking in terms of fires and floods. What is a real disaster for YOUR business? What are the likely risks you could face? Have you done a threat and risk assessment for your business? Few people could have anticipated the planes hitting the towers in 9/11. But some did predict the possibility of losing access to a building and developed strategies to ensure that the loss of their sites (and in some csaes their staff) to ensured they had a measure of redundancy continue operation - even if it was at a reduced capacity - in the case of such an event. <br />
<br />
Real contigency plans can be constructed around a number of scenarios. For example:<br />
<ul><li>Loss of buildings,</li>
<li>Loss of people,</li>
<li>Loss of critical services (gas, water, power, telecommunications).</li>
</ul>These could be trigged by anything (fire, flood, even acts of violence such as shootings, etc). <br />
<br />
While it is impossible to have a scenario for everything, developing even a single strategy is simply the beginning to a wider strategy. Having a process (even an imperfect one) means that you have something which can tested annually and improved it over time. This already puts you ahead of the pack.<br />
<br />
I've personally worked with businesses that have fully accepted the risk of not having a DR or BCP strategy based on their estimation of likelihood. I think these incidents have well highlighted that such short sightedness can be damning.It doesn't have to be a fully redundant cutover. You just need to be realistic. Your BCP/DR strategy may only allow for limited or even reduced capacity based on cost constraints. But hey, something is better than nothing.<br />
<br />
I don't want people to think that I am trying to milk these tragedies for chalking up posts ont his blog. My intention is the opposite infact. My point is that there is a greater tragedy here - that these incidents have occured and yet, we still don't seem to be learning.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com3tag:blogger.com,1999:blog-5388115022531534533.post-48151297112593351222011-01-11T20:00:00.000+11:002011-01-11T20:00:39.856+11:00Vodafone Privacy ScandalHappy New Year to everyone.<br />
<br />
Interesting that I get to kick off my first post of 2011 on what could be considered the largest privacy breach in Australian history.<br />
<br />
In away, I think we need to be greatful that the <a href="http://www.theage.com.au/technology/technology-news/inquiry-into-vodafone-data-breach-20110110-19l89.html">Vodafone</a> <a href="http://www.theage.com.au/business/search-intensifies-for-vodafone-gremlins-20110110-19l68.html">privacy</a> scandal has drawn so much attention. We (Australia) never had our Heartland or TJX or anything like that. Our complacency and lack of strict privacy regulation means that we don't get to see the notifications of privacy breaches. Some companies, such as Telstra have "voluntary notification policy" concerning privacy breaches but perhaps I'm one of those skeptics who wonder just how much they would "volunteer" if they were put to the test.<br />
<br />
Potentially, this incident has the chance to bring about change on the legal landscape. In reality, it is no doubt being lost in the deluge (no pun intended) of news concerning the Queensland floods.<br />
<br />
There is a lot of blogging going on about the basic security controls that Vodafone could have/should have implemented but didn't. I'd love to wag my finger at them and say how naughty they are but the reality is that this is FAR MORE COMMON than most people are aware of and what security professionals can tell. <br />
<br />
The best thing security conscious folk can recommend is that if consumers give a shred about their personal information in any respect (including SMS messages and call usage btw) then I suggest you push anyone and everyone you know who is using Vodafone to another carrier. I am already telling immediate friends and family who use them to make the switch. I urge you to do the same.<br />
<br />
The only thing companies understand are dollars and cents. So make the message strong and clear - <i>tell these businesses we will <b>not </b>accept poor security</i>. Personal information does have a value and its high time companies recognise the cost of failing to protect it.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com2tag:blogger.com,1999:blog-5388115022531534533.post-41522961656679526842010-12-20T00:42:00.000+11:002010-12-20T00:42:37.210+11:00My $0.02 worth on outsourcing securityI have had some discussions with people surrounding this topic lately and I want to highlight a few points on this very tender topic.<br />
<br />
Firstly, I am not in favor of offshoring security testing. It needs to be said. I acknowledge it is happening, I acknowledge there is an economic benefit in doing so, I understand why this is happening - but it isn't something I'm happy with. Then again I'm not happy with a lot of things but we have to make do with what we've got sometimes. I also think a lot of people rage about it without a clear grasp of what is "really" the problem. So I want to put out a number of ideas out there what I think people are sensitive about and with that in mind, try and put it into perspective. Moreover, I want to stress in economic terms why this happens and is "normal" (in an economic sense of the word).<br />
<br />
I've included some common economic principles below that I have personally found really interesting in studying this for my MBA. Contrary to popular belief, economics is not just about business. At its core, it is about how people make decisions and evaluate choices. Everyone should study a bit of economics IMHO. Even if you have no interest in business, it can help you with your social engineering efforts. :) Anyway, this segues into my next point.<br />
<br />
Economists discuss that when people make a decision (such as purchasing another unit of a given good) they evaluate what is the benefit in doing so. Some companies have already made the decision to move a good number of critical functions offshore gives them a much greater benefit. They can put the cash saved towards purchasing more security consulting, buying more widgets, giving execs larger bonuses - whatever. The point is the decision has been made that they perceive there to be a greater "gain" in this move. <br />
<br />
Thirdly, the whole "outsourcing" security is precisely why security consultancies are built. Businesses outsource their function to specialists every day. It makes sense. Anyone that is even slightly familiar with economic theory will understand that it makes sense to employ specialists where needed when a specific skill competency is outside of your core business. So the whole idea that "outsourcing = bad" must be utterly dispelled. It isn't "bad". To say it is bad is a strawman argument. When I was hiring pentesters in my last job, its because I am snowed under, I wasn't getting time to develop my own skills and yet expected to attend 5+ hrs of meetings/day. It made perfect sense for me to hire guys who stayed ontop of their game and were paid to keep their skills sharp, to say nothing of obtaining objective, independent testing. So lets get that out of the way. It happens every day, what we're talking about are these services either moving offshore or to more unskilled labour - that is what gets most security consultant's goats up. If you get a plumber in to fix your pipes, that is "outsourcing". Service your car? Outsourced. We do this every day, only we don't perceive it that way. Ever buy a car? Probably imported. I can go on but the point is that "outsourcing" is another word for "trade" (see Principle #5 below).<br />
<br />
Fourthly. the outsourcing argument assumes that Australia has a monopoly on technical acumen - and that's simply not true. We are a very small player on a global stage. To be fair, I also think a good number of our homegrown talent is largely uncredited (but that's another issue). But I'll pick on India since its a hotspot for outsourcing and there's a lot of good discussions and research on this topic in relation to India (so it suits for reference purposes).<br />
<br />
<br />
For starters, India's IT schools are regarded as an asset of national critical importance. They also have a much larger population, an incredibly larger proportion of people going through university (1.1 billion people estimated, 7% post secondary education vs our 22 million population and 34% post secondary education). Right away, they have <i>three times our national population </i>with a tertiary education. Granted, there are cultural issues which suggest that many graduates are <a href="http://www.economist.com/node/15393732">not well suited</a> for many jobs (cultural attitude to <a href="http://www.expressindia.com/latest-news/rote-system-of-learning-still-rules-the-roost/375996/">rote learning</a> <a href="http://www.businessweek.com/magazine/content/04_22/b3885015.htm">apparently</a>) but if you consider the pool of potential graduates coming through, statistically they have enough people they can (almost literally) throw at the wall and see what sticks! Even if there is evidence to suggest they aren't all appropriate, the fact remains that even if you look at the guys with talent, there is almost a statistical certainty that they will have more technically capable guys than we do in Australia. It's arrogant presumption to presume we're so awesome that they can't compete in the same space as us. One of the beautiful things about technical skill is that it is not constrained by country, economic wealth or privilege and does not care about culture barriers. This is what is great about tech and what brings techies together around the world. Likewise, its the Achilles heel which ensures that the industry will always trend to being outsourced.<br />
<br />
Bringing the point home, its not difficult to assume that if I can keep a close eye on how I outsourced my pentest and manage assurance with virtual team then certainly other companies can't with outsourcing. That's not to say crap work can be delivered by unskilled labour but lets be frank, we've seen that with local assets too, right? :D I see that as a management problem, not a delivery problem. Don't believe me? Ask any tradie who has to oversee first year apprentices fresh out of high school.<br />
<br />
Finally, I.T. security has been largely a growth industry and despite hearing it is almost a recession proof industry for years, its interesting that only now we're being hit with the outsourcing. Having grown up in I.T, I've seen this so many outsourcing gigs hit jobs of either friends or family that I've almost become inured to it. I know people are thinking "OMFG pentesting gone to India wtfbbq" and its like yes, welcome to the 21st century. We are all expendible. Now as mentioned, I am opposed to outsourcing this function because I think sensitive information gathered from pentesting needs to be kept close to home with strict governance around it along with stringent quality assurance. However, we all know about the insider threat so again - its a strawman argument to assume it can't happen here. But the reality is we are not unique and beautiful snowflakes. People will outsource to companies if they can do it cheaper - even if there is a drop in quality. If the quality drop is still within an acceptable level, then meh - they'll wear it. I'm not saying it is right, but this is what Mankiw calls "the margin" and its here to stay (always has been really). I was actually going to graph this point but I'm tired and can't be arsed. If you're actually interested, go study 'price equilibrium' or 'equilibrium theory' (the two aren't the same but they are related) and you'll see what I'm talking about. <br />
<br />
<br />
Ultimately, the problems that arise from outsourcing are largely the same problems our clients today face when decide to engage us as consultants. I share the same trepidation as everyone else but I don't think the problem is as concerning as everyone makes out. We just need to be very clear on what those problems are and ensure that we impose suitable checks to offset those risks and have some sound advice for clients looking to move down this path.<br />
<br />
If you're a company competing against outsourcing, my recommendation is to study Mankiw (see below) and have a think about how you could apply these principles in effect to your work. I have many ideas on how I'd compete against anyone simply offering a lower daily rate against my business. Some of them aren't entirely fair either. ;-) In any case, there are somethings I won't post because we're competing against this crap too. :) One strategy I will offer is that I am a firm believer in uplifting our capability and focusing on delivering business consulting and security strategy (see #4 below and my previous rant).<br />
<br />
Cheers,<br />
<br />
- J.<br />
<br />
<b>Resources:</b><br />
<b>N. Gregory Mankiw - 10 Principles of Economics.</b><br />
<br />
#1 People face tradeoffs<br />
#2 The cost of something is what you give up to get it<br />
#3 Rational people think at the margin<br />
#4 People respond to incentives<br />
#5 Trade can make everyone better off<br />
#6 Markets are usually a good way to organize economic activity<br />
#7 Governments can sometimes improve market outcomes<br />
#8 A country’s standard of living depends on its ability to produce goods and services<br />
#9 Prices rise when the government prints too much money<br />
#10 Society faces a short-run tradeoff between inflation and unemployment<br />
<br />
<b> PS:</b> I recommend "<a href="http://www.economistsdoitwithmodels.com/">Economists Do It With Models</a>" as a great resource for understanding economic concepts in bite sized chunks. Jodi Beggs is actually a former student of Mankiw and better able to conveying information than the textbook I have to use for my unit. :-( Yes, the link is worksafe btw, don't be put off by the name.<br />
<br />
<br />
<b>PPS: </b>I had a whole rant where I was actually going to discuss price elasticity of demand with regards to security services but I realised that its not relevant to this discussion and decided to drop it, but I'd be keen to hear from other security folk who are actually interested in this stuff on what they perceive as the elasticity of security services to be. I'm of the very its actually quite elastic based on my own experiences but I realise that flies in the face of a lot of evidence to the contrary. Then again, I suspect I might be an anomaly in this area...Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-21638261803427806852010-12-19T11:16:00.000+11:002010-12-19T11:16:10.117+11:00Pentesting isn't enough - "Part 3"My friend Serg over @ SecuritySoup.com recently made <a href="http://www.securitysoup.com/?p=76" target="_blank">these </a>two<span style="color: black;"> </span>posts about pentesting and I must admit it gladdens me immensely to see posts like this. I won't divulge too much about Serg in the interests of maintaining his privacy but I will say he is an experienced penetration tester and security consultant and in short, knows what he's talking about. Before I begin this post, you really need to read what he's written first.<br />
<br />
I think I'd learned this lesson several years ago in my last job - and I know he has too but I think for Serg had the points hammered home to him over the past two years in particular on the basis of some of the clients and types of engagements he was working with. It's one thing to know something but another entirely to have the point really hammered home to you or see it demonstrated time and time again.<br />
<br />
One of the things I am convinced you become aware of the longer you work in technical security space, the more you realise that the governance and management aspects play a critical factor in ensuring the success of a security program. Having said that, there's a world of difference between wanting to be a security manager and recognising the need for security management.<br />
<br />
I have no desire to be a manager myself but I've seen first hand why non-technical skills are absolutely critical to ensuring the success and I'll give you an example:<br />
<br />
I was a security lead on a very large project (large iconic brand shall we say?) and the one project was going to bulldoze ahead to go live without a critical security feature which was absolutely necessary to ensuring success. Without it, I am talking front page news headlines, loss of consumer trust, irrepairable brand damage, basically a post-apocalyptic security nightmare. At this point in my career I had come mostly from a tech background and I had flipped out that this was going on. I realised that the Project Managers, Business Analysts, Programmers, etc. --<i> NO-ONE</i> cared about security.<br />
I couldn't understand why.<br />
<br />
<br />
I had to learn (this job was a real baptism by fire let me tell you) how to convince people. I had to relate these risks back into business terms that they could relate to and why they needed to.<br />
<br />
Pretty soon, nobody saw the problem I pointed out as a "security problem" it became "a problem" that each project member saw in their own way. The Marketing head saw it as being "detrimental to the end user experience". The Governance board envisioned "irrepairable brand damage". The Head of IT imagined his entire online presence having to be rebuilt and his Application Support team working overtime for the next six months. I eventually got funding to do the work that was needed and divert resources to develop the necessary controls to prevent this from happening.<br />
<br />
Now if you are just a pentester and all you know is how to break stuff, then I suspect you would find it highly challenging having the above conversations. Infact, I know plenty that have no interest in having those conversations either - and that's fine. It takes all sorts of people to make this world go around and it would be horribly boring if we were all the same.<br />
<br />
But to be a consultant you do need to be able to have these discussions with a variety of people. You have to understand what motivates people and speak to that motivation. Tony Robbins is often quoted as saying that people will do more to avoid pain than to gain pleasure - and this is certainly true in a business context.<br />
<br />
<br />
Serg's point is that too many people lack these skills and it is these skills are most important. With the increase of technical jobs going overseas, the critical differentiator becomes the understanding of the client's business and how security fits into that. This is the lifecycle he's referring to. These are the sorts of questions such a consultant might find himself asking:<br />
<br />
<ul><li>How does penetrationt testing fit into your application development process?</li>
<li>How much of that testing is handled by other test teams before a security specialists does?</li>
<li>Are you doing code analysis, threat modelling, architecture reviews prior to development?</li>
<li>Post launch, who is monitoring your applications, infrastructure and your data and how?<br />
</li>
</ul>By no means is this list comprehensive but demonstrates the point.Technical skills are important. But to work in today's world as a consultant, you need more than that. I've worked with some brilliant technical minds (and I mean <i>brilliant</i>, not just skilled) but could also understand clients and their businesses. They can pentest anything you put infront of them (and I mean <i>anything</i>). It is certainly possible to have a good mix of both. The question is whether you want that mix of skills? If you want to remain a consultant in today's market, you have to have a service differentiator.<br />
<br />
<br />
Now if you're relying on technical excellence as the only factor, you may be in for a very rough time. The basic law of economics dictates that people seek alternatives. If they can get the same service from someone overseas for a fraction of the price for equal skill (or even lesser skill) then a lot of people will make the trade-off if they <i> perceive </i>it to be of value. I'm not saying this is right or wrong, but that's the way it is. There are ways of dealing with this but we - as an industry - cannot continue to do what we always used to, never change and expect things to function as they used to. Times are changing and so too must we.<br />
<br />
I guess the crux of the post is this -<br />
<br />
<br />
It's one set of skills to be a hacker. It's another set of skills entirely to be a security consultant. Being one doesn't automatically make you the other. Serious hackers laugh at guys like me with their CISSP. That's fine. I laugh at guys like them who wouldn't last a week in a corporate enterprise environment dealing with the baggage I've had to. Like I said before, it takes all sorts to make this world go 'round.<br />
<br />
I read Serg's post is a wakeup call to the pentesting community. If all you know is how to pentest, then times are looking grim. If you cannot properly engage the business, understand their language and communicate in their terms, think in abstract terms of principles and concepts and not just lines of code, then you better start learning or otherwise re-evaluate your day job. Your job is going to go to India or the nearest CompSci grad with a CEH who will undercut your daily rate.<br />
<br />
If you don't believe me, then you better open your eyes. It's already happening.<br />
<br />
<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-21701730052509030332010-12-03T23:13:00.000+11:002010-12-03T23:13:35.722+11:00Wikileaks getting shaftedI remember seeing Julian Assange speaking at one of the Ruxmon meetings earlier this year and not long after, I got into a discussion with another infosec consultant who was in attendance. We were discussing whether we thought Wikileaks should have posted the <a href="http://www.collateralmurder.com/">Collateral Murder</a> video. His view was that, while disclosures are necessary, he wondered if this was really a case of "fog of war" and whether the video was more an indication of an unfortunate, grizzly accident rather than a grotesque abuse of power (force of arms).<br />
<br />
(Now, to be fair, Assange went to great lengths to explain the rules of engagement as officially passed down to military personnel to highlight the fact they had clearly violated said rules to carry out the attack.)<br />
<br />
I was polarised at the time. I used to be a far left hippy in my youth but I think overtime I'd become more bipartisan in my thinking. I could see both sides and I have a tendency to play devil's advocate. I think I said something about "yeah but we need groups like Wikileaks, to keep governments accountable." Say what you will of the Collateral Murder video but you have to admit, if the purpose of government is to serve its people then the idea that it should also be answerable to the people, isn't a stretch (unless you support dictatorships or other forms of non-democratic government, in which case I think we're on different views and you should stop reading).<br />
<br />
The point I'm making was I really didn't feel strongly enough one way or another, but notionally, I supported the organisation.<br />
<br />
Then someone else this week suggested creating a new root DNS server, in opposition to ICANN's management. My initial thought was "Ok great, someone wants to setup a new root but how do you secure it and prevent flagrant abuse?" This is a governance problem, not a technical problem - hence my tweet on the subject.<br />
<br />
Not long thereafter, Wikileaks got DDOSed. Then the site was dropped from Amazon. Then their DNS provider dropped them.<br />
<br />
At first I was shocked. Then I was scared (yes, scared that this could happen as naive as that may sound).<br />
<br />
And then I got <b>angry</b>.<br />
<br />
One of the roles I used to work in was Network Abuse, where we used to deal with investigations ranging from professional spamhaus gangs, to child pornographers, to kiddies dealing trojans to steal Diablo II accounts, you name it. We used to deal with other ISPs to collaboratively take down sites or offenders of clearly malicious intent. It was like a code amoungst ISPs - even if there is no direct law for some of the things we did, we did it because it made sense to work together as a global community (of course emailing non-English speaking countries was always a challenge but I digress).<br />
<br />
You could argue we took the law in our hands, but we acted when the evidence was overwhelming that these people were malicious. E.g. evidence of spam traceable to certain IP blocks. Abused credit card numbers. URLs of sites allegedly hosting kiddie porn, etc.<br />
<br />
Today I just saw a bunch of companies give strawman excuses to drop Wikileaks like a hot potato, for reasons I can only attribute to political pressure or unsavory conditions. I get DDOS as a weapon of hacktivism - I understand the motive. But these companies wiggled out of the arrangement for very dubious reasons. The US Government which claims to protect individual freedoms and rights is using every means at its disposal to capture Assange and arrest him. Swedish authorities have acted against their own law, with <a href="http://radsoft.net/news/20101001,01.shtml">largely uncredible testimony.</a><br />
<br />
The bottom line is this - even if you didn't support Wikileaks before, the actions of all these various groups is actively working against them, as it will polarise various groups that would otherwise have remained enemies. I'm only one random dude with an Internet connection and a pedestal, but I can find myself in agreement with so many people I wouldn't have yesterday, how would some other folks out there feel, particularly those with more spare time, motivation and technical savvy? I can only imagine.<br />
<br />
In Australia we've never had to fight for our independence or freedoms. We have no Bill of Rights. Subsequently most Australians really are largely apathetic to the notion of free speech. However, if you've lived abroad or travelled to communist or non-democratic countries, you begin to realise just how valuable it is. We may have no such war but I cherish it.<br />
<br />
Today made me think that I am far, far more left wing than I ever thought I was and it sent a shock through me. I wound up making a donation to Wikileaks. Nothing large but enough to at least send a token of support.<br />
<br />
I support Wikileaks because there may come a time when I need a voice for something I cannot say myself. I support Wikileaks for my family, friends and other people on this planet who may find themselves one day in a god awful place where they need a voice and Wikileaks is the only one who can provide it. There are some real scumbags on this planet who should be punished but they hold the balance of power. Wikileaks has real power to make those people answerable to a higher power. Without groups like them, the bad guys can and will win.<br />
<br />
Even if you haven't always agreed with their actions to date, ask yourself:<br />
<ul><li>Do you believe that businesses and governments alike should be answerable to the people?</li>
<li>Do you believe that no-one is above justice?</li>
</ul><br />
If you answer yes to either of the above, I also encourage you to make a donation to Wikileaks and support the cause.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-12223929170062489842010-12-02T23:18:00.000+11:002010-12-02T23:20:44.130+11:00Problem SolvingI recently read a presentation by Ivan Ristic (ModSecurity fame). You can find it <a href="http://blog.ivanristic.com/Ivan_Ristic-Stop_Complaining_and_Solve_a_Security_Problem_Instead.pdf">here</a>. It struck a chord with me and I wanted to share this gem.<br />
<br />
In infosec we suffer either one of two conditions (generally) - either we suffer from tunnel vision, focusing on minutae that are rarely of any real relevance to the task at hand, or we attempt to "boil the ocean" in an attempt to solve unsolvable problems.<br />
<br />
Ivan's post basically made a very practical recommendation - don't boil the ocean, focus on one problem at a time.<br />
<br />
We are all confronted with a variety of problems, either at work or at home and it becomes very, very easy to start lumping isolated problems together, creating a snowball effect. Sometimes they are related but sometimes when you have an emotional investment in something you can't see that the forest is made of individual trees. :)<br />
<br />
I am meandering a bit (I tend to if you haven't figured it out by now - sorry) but my point is that while its important to look at the big picture, make no mistake we can only solve one problem at a time.<br />
<br />
Extrapolating this to infosec, each of us see something that we as individuals can "fix". I want to put it out there that there are problems we can fix, we just need to pick them off. I've got my own bugbears I'm thinking about and if I have to pick one I want to focus on, it would probably be patch management on an enterprise scale. I'm not sure I can "fix" this but I am pretty sure I have some pretty practical suggestions that would go a long way towards doing so. I'm still contemplating how/where/when I'll go abouts working on a presentation on it.<br />
<br />
Anyway, I'm sure you each have one thing you want to fix or more importantly, can fix. I want to emplore anyone reading this to do it.<br />
<br />
We may never solve the "security problem" but we can all certainly play a part in trying to fix it. I'd rather be part of the solution than part of the problem.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com1tag:blogger.com,1999:blog-5388115022531534533.post-35812256062248580422010-11-25T23:40:00.000+11:002010-11-25T23:40:58.026+11:00Why everyone in infosec should do SABSA trainingLast week I did my SABSA training and certification. I don't know how I went but I wanted to share the results of what I learned.<br />
<br />
This post is long and I make no apologies for it. I wish someone had a post like this before I started on the training. I didn't have anyone I could turn to or who could really tell me what it was about until I had done it (which was frustrating). I mean I asked around but I didn't get an answer that really satisfied me. So I wanted to give the best writeup that I could to help explain to any other likeminded folk in the field or least give my thoughts on what I walked away with. So here it is.<br />
<br />
For the uninitiated, SABSA stands for 'Sherwood Applied Business Security Architecture' and it is a method for applying an understanding of the business you are securing. By understanding the business, you are able to build in security that is appropriate to the context of that organisation.<br />
<br />
My career journey has taken some very bizarre turns. When I took up my last role, I wanted to move into focused pentesting (from a role where I did some pentesting) and instead wound up doing a combination of stuff - security management, security consultant and solution design and architecture. I got to oversee a bunch of pentesters, hire pentesters and be fairly involved but it became a gradual divorce away from the hands on (which I still miss sometimes but other times I don't). But more to the point, I <i>enjoyed </i>what I was doing, although I think it took me a time to really appreciate it because it wasn't what I signed up for.<br />
<br />
Anyway as I came from more of a sysadmin/pentester background, I would look at project designs and how to break them (typical 'break' vs 'build' mentality). Reviewing security controls because a question of trying to be as thorough as I could, and an exercise in mentally threat modelling various ways to break the solution design. <br />
<br />
I would look at different methodologies for security testing, I would think of solutions in terms of the OSI model and what security services were required (authentication, authorisation, auditing, etc). I looked at OWASP to ensure a stringent design process was followed. We used contractual arrangements to enforce our needs where we could. I'd spend time talking to the business and trying to spend more time listening than talking. I wanted to find out what their problem was and if I could address it. I also tried to keep up with all the tech (which is impossible once you get to this point doing this work as something has to give).<br />
<br />
But the whole thing seemed and felt <i>really adhoc</i>. It was a case of finding what I could think of, springboarding ideas with my team mates and consistently asking myself "is this enough?".<br />
<br />
I couldn't put a label on what I did exactly - but whatever it was - I was never aware of a methodology to help people like me doing the work I was doing. I became aware of architecture as a discipline owing to some good solution architects who heavily influenced my thinking and became aware of Enterprise Architecture as a discipline and how good solution design can help drive strategy. However that seemed great as an IT Architecture, or a Business Architecture, but nothing to help me in my discipline. I learned relatively quickly that pentesting was simply a way of measuring security effectiveness but in and by itself, didn't offer me anything beyond some assurance. It was around then I started to drift away a bit from pentesting.<br />
<br />
I became aware of SABSA in 2008 through a co-worker. We'd both found the SABSA book by David Lynas, John Sherwood and Andy Clarke but neither of us really did anything with it. I think at a glance we had the same impression as everyone else. It looked great as a method but seriously, how practical was this light and fluffy stuff. We both came from similar backgrounds and I think had very similar thoughts on applying architecture - this all looked really high level theory and not very practical.We were still interested in the book and how it applied but we never got around to reading the book or doing the course.<br />
<br />
Well, I finally started on that book earlier this year and got through most of it (3/4 I think). The course is an equally tough slog too. I consider myself pretty passionate on this topic btw, but after day 4 even the most passionate person will be tested I reckon!<br />
<br />
As I went through the training I had an epiphany of sorts (actually I spent a good chunk of the weekend at Ruxcon ruminating about it too). Having read the book and seen some videos on architecture, I had some idea of how Architecture, as an IT discipline worked. But this course really highlighted for me why SABSA is THE single most important training I have had in my field to date. I wanted to share what I learned and highlight why I think other infosec professionals - regardless of their role, should do it.<br />
<br />
<b>What I learned:</b><br />
I learned that the often disparate array of compliance standards, ISO standards, architecture frameworks and so on need not be. They can all integrate together. Once you understand the business you can begin to build that picture. The architecture frameworks (TOGAF, SABSA, Zachman, etc) are simply a "method of organised thinking". SABSA is the concrete which enables me to put together all the other building blocks together.<br />
<br />
Every thing I know, have learned and will learn (not just security related) I can apply using this framework to build a security model for my clients based on re-usable architecture. The "architecture" however, is never complete. It is a living breathing organism. Each project or each pass is an attempt to iteratively build up your understanding of the business. Each project is an opportunity to build upon those building blocks - re-use what you can or tailor to suit where appropriate. You never have a perfect "target". It just keeps moving. We've often known that security is a journey, not a destination - but seeing this through the eyes of an architecture framework is a very different thing. I think its like trying to describe being a parent to someone who doesn't have kids. There's the difference between knowing the path and walking the path, as Morpheus would say. :)<br />
<br />
From a technical viewpoint, I learned how to structure controls so that controls at the various OSI layers are not done in isolation from each other. That you can build concrete controls. You can even forgo certain controls but it is not without an understanding of the potential consequences or the risk. I also learned to truly build re-usable, extensible security services. Moreover, how they link back to business goals and objectives which enables demonstrable return on investment and develop a realistic form of risk assessment (pretty much the best system for risk assessment I have seen to date).<br />
<br />
Incase people reading this think this is all high level fluff, the guys who developed this were the architects for Swiftnet (the system banks use to transfer funds internationally). Anyone who has heard of this or worked with banks will understand the importance of the system and the risks involved. As you go through the training, David Lynas (who is the main instructor globally - if not the only one I am aware of) will make clear his points through illustrated examples throughout his career and using examples from other people's careers. As someone who had done this sort of work before, I found these some of the most educational points of the training as I could relate it back to various situations of my own and either pat myself on the back for getting something right or mentally kick myself for thinking how I should have handled something differently.<br />
<br />
I realise this is going on and on - but I really want to stress why I think this is worthwhile. I try to provide some context here based on a person's title/role or aspirantions here:<br />
<br />
<b>Security Managers/CISOs/CSOs</b><br />
The SABSA framework integrates with just about every relevant standard or framework you can think of (ITIL, COBIT, ISO27000 series, etc) and a way for running security programs. It provides a method for delivering business driven security services with mesaurable results and a PRACTICAL form of risk assessment (the most practical I have seen). The risk management framework and how to measure security, will be worth the price of entry alone for you. <br />
<br />
<b>Security Designers/Architects</b><br />
I think you'll come away with a similar view to myself and see how this all ties everything in together. Management, penetration testing, security standards, compliance, risk, technical controls and how to integrate them all - in a practical method. You will enjoy the focus of building and creating at a truly enterprise level and your game will be taken to another level.<br />
<br />
<b>Penetration Testers/Security Analysts</b><br />
Pentesters are a funny lot with their training budgets. Either they want to do Offensive Security course or for the more advanced ones, a top notch Immunity course by Dave Aitel - or they are usually happy to spend their own time with a few books and play around with stuff on their own. Now if you fall into the later category, you should definitely put it towards SABSA.<br />
<br />
I mean lets face it - you're not going to put the budget towards anything else, why not learn how to review solution designs using a comprehensive strategy which will enable you to cover all the components? Why not learn how to link it back up to core business objectives? Truth is that will not take away from your technical skills - why not learn how to engage with the business at a higher level.<br />
<br />
The short answer is if you haven't done the SABSA training, just get out there and do it. It will not takeaway from anything you have done to date. I can assure you it will only complement anything you do, regardless of what it is. And finally, I think it will really open your eyes in ways you hadn't considered previously. It won't solve world hunger and the "security problem" for good, but I will say that it is a damned good start. If more people had done this training in our field, I can honestly say that the world would be a safer place.<br />
<br />
I hope this is useful.<br />
<br />
Cheers,<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com22tag:blogger.com,1999:blog-5388115022531534533.post-53133268371719396932010-11-22T22:07:00.000+11:002010-11-23T20:28:25.408+11:00Ruxcon 2010 & my talk: "No Holds Barred" Penetration TestingEDIT: My Rapidshare link broke so I've resubmitted it using Google Docs.<br />
<br />
Well my talk at Ruxcon is said and done. My slides can be found <a href="https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B15_RrJV4jy1MDdhZGY1ZWMtMGJhYS00NTFiLWE3ZGYtMmFhN2U5MTc1NGY5&hl=en&authkey=CJTqrN8M">here</a>.<br />
<br />
Truth be told, it went better than I expected. I was worried that since I was not posting 0day code or providing a tool that there would be no interest. I don't think anyone was more suprised at seeing a fully packed room than me. <br />
<br />
What started was going to be a series of grumblings about my views on penetration testing today ended up being more clearly focused on client side penetration testing.<br />
<br />
I know plenty of consultancies are technically capable and some might even have done client sides, but to the best of my knowledge I hadn't heard of any in Australia doing so. And if they did, they kept their cards very close to their chest. Or more to my thinking - they have done it but I think the repeatability might have been lacking.<br />
<br />
Obviously a lot of this is just guesswork on my behalf and there was a limit to how much research I can do this on this front - so a good chunk of the talk was based purely on my own experiences in the field as someone who has hired pentesters and now working at a consultancy where we do pentesting (amoungst other things).<br />
<br />
One of my gripes is that we are lagging behind our competitors in the sense we aren't actually doing client side penetration tests (as a general rule) in AU, at least not on the scale that happens in other countries. I think this means that there is a significant gap in terms of the coverage and assurance that our penetration testing coverage truly provides.<br />
<br />
I want to raise awareness of this issue and really try and provide some suggestions how both parties can lift their game and get more of these happening. How both parties can try selling the service, when it is appropriate, how to justify in a business context, provide ROI (yes, it is possible), etc.<br />
<br />
On Ruxcon, I have to say I was really impressed with the quality lineup, the registration, the management of the event - even little things, like the way the bartab, water even the toilets was handled. Hell, even Black Hat @ Caesar's Palace ran out of water. What does that tell you?<br />
<br />
The CTF ran flawlessly (barring minor performance issues) which when you compare to previous years, are still trivial in comparison. If I had to come up with one gripe, it would be that the area infront of the bar was too small for the size and we wound up having to really yell to be heard, so I've subsequently lost my voice. I forgot to mention I like the fact that despite corporate sponsorship, there was no blatant advertising, no "vendor streams" and no bias towards speakers who happen to work for sponsors. AusCERT take note!<br />
<br />
I've said it before but I must say it again - it was by far and away the best Ruxcon ever. If you have to pick one conference in Australia, make this your one.<br />
<br />
Cheers,<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com2tag:blogger.com,1999:blog-5388115022531534533.post-47432088958264551192010-11-21T17:27:00.000+11:002010-11-21T17:27:38.352+11:00Ruxcon, SABSA and more random bitsGidday<br />
<br />
It has been awhile but I will do a proper blog update soon. This week has been a build up for me on a number of levels, I've been up in Sydney completing the SABSA training, trying to study for that, polish up my talk then race back for Ruxcon. That and trying to sort out some admin issues with university meant I've been significantly under the pump and it all came to a head this week. So subsequently I've gotten sick and had to leave Ruxcon early (clearly I'm not up for this touring lifestyle).<br />
<br />
I wanted to talk a bit about my talk, post the slides and some other odds and ends, so I'll be doing that in the next day or two.<br />
<br />
But just briefly -<br />
<br />
Ruxcon 2010 was the best year in the history of the conference. Props to Chris and the crew for organising it and the success. It is very clear he's learned from the successes and failures of other conferences and avoided all the pitfalls. To the degree that I would recommend overwhelmingly if you had to pick one conference in AU to attend, without a doubt, make it this one. I was very disappointed by AusCERT this year and I can safely say that I would not be keen to attending.<br />
<br />
Secondly, the SABSA training really changed the way I look at architecture. This topic deserves a post on its own right and it will be forthcoming. I want to stress that this course is of benefit to ANYONE working in infosec -- I don't care if you are a pentester, a manager or an architect. David Lynas was able to really highlight how it all fits together with real world examples.<br />
<br />
I guess, I had a kind of Neo moment (ala. The Matrix) where I feel like I 'see' the code now. It is all a bit hard to explain right now (given my sinus infection) but let me just categorically state that this course, the book and certification I believe to be strongly worthwhile. So go pick up a copy of 'Enterprise Security Architecture' by David Lynas, John Sherwood and Andy Clark. You will not be disappointed.<br />
<br />
Anyway, I will update more soon but as this is my first conference presenting and when guys like Brett Moore, Billy Rios and Silvio Cesare are presenting, its an honor to be on the same list of speakers. I'm just grateful for the opportunity to speak. I sincerely hope that even if people disagreed with my views that some of the points made can be taken and leveraged in some way to gain better traction on client side penetration tests.<br />
<br />
I hope you all had a terrific weekend and enjoy whats left of the conference.<br />
<br />
Best regards, <br />
<br />
- J.<br />
<br />
PS: My apologies to Daniel Grzelak. If you read this mate, I know I promised to be there (as you are speaking as I write this) but I am really not well. Sorry to let you down, but I know you'll kick ass.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com0tag:blogger.com,1999:blog-5388115022531534533.post-14513541069736573902010-10-13T21:37:00.000+11:002010-10-13T21:37:42.193+11:00Why DO projects fail?I don't want this post to degenerate into a mindless, multi part rant as if I have all the answers as to why projects fail. However I felt that at least one post one the most common cause of project failure that I have witnessed is most undoubtedly worthy of such a mention.<br />
<br />
<b>Strategic alignment. </b><br />
<br />
Well - duh, I'm sure most infosec guns out there would say. But what does that mean exactly? I had to conjure up a bit of a buzz phrase to encompass all the instances of which I've seen lead to project failure. So let's break that phrase down.<br />
<br />
<br />
I'll give you a hypothetical example:<br />
You are a security lead in a program of work. By program, I mean overarching stream consisting of multiple projects.<br />
For simplicity's sake, lets assume it is a business transformation program where multiple core business objectives are expected to be achieved which will ultimately revolutionise the way that a business performs and conducts itself.<br />
<br />
Now of those multiple projects, lets assume each one has its own PM. Then its own IT architect. It's own security consultant. It's own business analyst, developers, sysadmins, and so on and so on. Now lets's all assume they each look at their own project in terms of its overall objectives and work. Each project is meant to provide deliverables that fit into a cohesive whole (i.e. the <i>program</i>, as opposed to the <i>project</i>).<br />
<br />
Still with me so far? Ok.<br />
<br />
For a moment, let us further assume that each project meets its deliverables and timeframes within budget (ok stop laughing - we're pretending ok? so go along). Unfortunately, there is one limitation.<br />
<br />
NONE OF THE PROJECT TEAMS CAN SHARE THEIR WORK WITH THE OTHERS.<br />
<br />
What is the overall impact towards the program?<br />
<br />
By assuming you're the program security lead, we'll further assume you have visibility of everything.<br />
<br />
Now lets say you see that the program hasn't correctly co-ordinated all the work between project streams, and also further assuming that the program isn't going to invoke the Hand of God and didrectly meddle with each individual project when there is a problem, chances are that there will be a high cause of failure. <br />
<br />
If each project is providing a deliverable that has no visibility of the end game or 'desired target' that is the commonality that all the individual project streams are supposed to be working towards, then nobody knows where they are going. Projects provide their deliverables in a vacuum. The net result is you will have a very unsatisfied business sponsor who is in all likelihood, going to ask the program manager to commit <a href="http://en.wikipedia.org/wiki/Seppuku">seppuku</a>.<br />
<br />
Infact, one of the sources I investigated as I was writing this stated the following:<br />
<br />
<a href="http://www.gtislig.org/Documents/10_Major_Causes_of_Project_Failure.pdf">"A project is considered a failure…whenever a project does not meet the expectations of the stakeholders."</a><br />
<br />
This is a rather apt description I would say.<br />
<br />
There are a raft of causes and reasons that projects fail. Many which you could argue aren't attributable to the above. However, if I was to pick the one cause of failure I see, it keeps coming back to a lack of strategy.<br />
<br />
Some examples:<br />
<ul><li>Point in time technologies selected to resolve an immediate problem with no alignment to strategy or architecture.</li>
<li>A program's risk registers not aligning to organisational risk registers.</li>
<li>Program leads disallowing information sharing between project streams.</li>
<li>Program leads not performing proper alignment of project deliverables to ensure a program's target strategic outcomes. </li>
<li>Ensuring the program has clearly defined outcomes from the onset (outcomes which are specific, measurable, achievable, realistic, timely - that is to say SMART) </li>
<li>Maintaining clear (and consistent!) lines of communication breakdowns between project -> program -> business sponsor. </li>
</ul> I could go on and on, but I'd <a href="http://en.wikipedia.org/wiki/Airplane%21">probably start to bore you</a>.<br />
<br />
The fact is that there is a raft of material out there which highlights the common causes of project failure, and the reality is we learn more from our failures than we do our succeses. Given IT projects in particular have an <a href="http://www.it-cortex.com/Stat_Failure_Rate.htm"></a><a href="http://www.claretyconsulting.com/it/comments/project-and-programme-failure-rates/2009-06-27/">aburdly high </a>failure rate , there is a plethora of information available for anyone to draw upon.<br />
<br />
I actually find this stuff interesting reading. If you read this stuff, I can almost assure you that you will be better equipped to recognise the symptoms long before the average PM does.<br />
<br />
As a security professional, your efforts can only be improved by recognising the common symptoms and causes. Try to understand the business and outcomes which are both tactical and strategic. Try to ensure an alignment with both and get your business stakeholder engaged and supporting your efforts. Once you do this, funding discussions also come a lot easier. If you can do this, you will almost assuredly find allies - for example, the architect on your side as well, who undoubtedly also grapples with strategic vs tactical battles daily.<br />
<br />
- J.Jarrodhttp://www.blogger.com/profile/09705073585945953338noreply@blogger.com1