Monday, July 8, 2013

Defcon 21 Fellowship Breakfast

For the past two years, I have organized a fellowship breakfast for Christian hackers who are attending defcon.  With out repeating all the details I've outlined here*, I'd like to continue the breakfast meeting again this year at Defcon 21.  This has been a great chance to just come and meet other brothers and sisters in our community who share a common faith.

In the past we have met at the Carnival World Buffet on Sunday at 10AM.  Although this location is ideal since it is in the hotel, it is also somewhat expensive.  Unfortunately there really isn't a less expensive option inside of the hotel.  As such, I'd like to plan on things remaining there.  If people would be open to something outside of the hotel, or has an idea of a more affordable place-- please let me know.

Please RSVP so I have an idea of how many folks will be attending.

* As a point of clarity, when I mentioned breaking bread I meant it only in the eating food together– not the taking sacraments.  This is a non-denominational based Christian event, if you define yourself in Christ– please consider coming.

Wednesday, April 17, 2013

Musing on OWASP

I have no qualms in calling out, before anything else, that it is my intention to run in the next OWASP board election.  In fact, I wouldn't be willing to do so without having some concept of what it is I would attempt to offer.  As I've struggled with that, some things have been become more clear to me about what OWASP is and what it's unique value could be.

Before I get there, I should also offer some thoughts about what OWASP isn't (to me).  I apologize for the tough love:

  1. OWASP isn't a definitive resource for developers to write secure code.  There are better resources for language specific issues (with relevant language specific examples) and implementation guidance all over the place.  Various frameworks like Ruby have whole security areas which cover in detail some of the more unique issues Ruby developers face.  Projects like the Common Weakness Enumeration (CWE)* do a great job in covering in non-language specific important concerns.  Many of the articles on OWASP are old and not as detailed as they ought to be.  I am more likely to encourage developers to study SDLC then I am to show them OWASP.
  2. OWASP isn't a definitive resource for web application penetration testers.  When people ask me how to get started as a tester, OWASP isn't really much of a consideration at all.  I point people to something like the Web Application Hackers Handbook, or Tangled Web.  If they can hang with those, the rest of their training revolves around studying how software work, reading specs, and reading/writing lots of code (of browsers, open source software, and even security tools themselves).  I have not read anything on the website that wasn't documented better somewhere else.
  3. OWASP isn't very cohesive.  There is a metric ton of stuff on their site.  What is more worrisome is that everything appears to be built in isolation and doesn't really have any notion of a theme.  For instance, why have "secure development principles" if none of your recommendations are tied to or aligned with them.  How does that line up to Top 10, or the ESAPI or OSAMM?
Those are three pretty big call outs, I know.  But what OWASP is, or at least could be, is very important to the community.  Specifically:
  1. OWASP is the very best bridge between management, development community, and -some- security testers-- nationally and internationally.  IME, the audience who typically attends an OWASP conference/user group is very different than any other "security" folk I know of.  In good ways.  They tend to attract significantly more developers and management teams than most other conferences.  This ability to connect people to things is huge.  If OWASP can connect people to more relevant information they need by: continuing to evangelize the need, developing relationships with people who deliver the best security content (for both builders and breakers**) it could be epic.
  2. OWASP is the one of the best project incubators for web security.  Even if you dislike OWASP, you can't tell me you haven't tried and used webgoat or one of their other tools (dirbuster) to get moving forward.  Even if you didn't, lots of other great projects were inspired by such ideas.  This is also, a pretty amazing thing.
So what would I do as OWASP board member?  I don't want to write out everything yet, but in short, I'd try to focus all the attention on those two things and dump everything else.  Most of the issues called out above stem from the fact that OWASP is trying to be everything.  It shouldn't, nor does it need to.  Unless OWASP can truly offer something unique in the field, they shouldn't be involved.  

This rugged minimization includes, dare I say, the OWASP Top 10 itself.  With security companies publishing heavily detailed and documented breach data, and information being made available to what attacks ARE happening-- what is the point of the top 10?  Why do I need a list of 10 things some folks THINK are valuable when I can get access to that data and make an informed decision for what is right to my company?


* yes, I am aware OWASP feeds into the CWE.
** I also dislike builder / breaker concepts-- but for sake of reading clarity I will allow it.

Friday, April 5, 2013

Three things for Developers to know

A few days ago on twitter I asked a question:
"If you could only teach a developer 3 things-- what would they be?"
After a surprising amount of retweets, I got back about 30 responses.  There were, however, some interesting tidbits / trends in my very informal survey.
  1. Input validation was the only centralized theme.  If it wasn't the first thing they brought up, it was still in the list.  Just about every response mentioned it.
  2. Other technical suggestions included: proper hashing, proper storage of data at rest, use compiler switches, session handling, and password management
  3. All other feedback was mindset / approach.
  4. There was only one mention of OWASP, and it was specifically the last thing to use if the first two (follow an architect's guidance on input validation || get a better architect) failed.
  5. No one mentioned anything in the top 10 (like, go fix SQL injection or XSS, or anything)
I should call out that I am somewhat biased. I think a vulnerability centric approach to teaching developers secure development is counter productive and not effective.  This micro-survey of what others would teach developers satisfied my curiosity and adds further evidence to my belief;  Teaching mindset/principles/code smells is more valuable than a list of common vulnerabilities that might affect their code.

I am putting a bunch of work into a talk/workshop on that effort.  I'd like to thank everyone who contributed so far.  If you didn't contribute before to the 3 things question, please feel free to do so below.


Saturday, March 23, 2013

CactusCon 2013

It is earnestly just such a humbling thing to help run a conference.  Technically speaking, I hold the 'lead organizer' title-- but it is somewhat meaningless.  There is so much that needs to happen and without the help of a bunch of people, it couldn't (Specific kudos to Phil, Skyler, and Jessica).  I did not do anything much, we did.

So.  What exactly did we do?  If we take a quick journey back in time, a few friends got together and asked the question, "why can't we have a hacker conference here in Phoenix?"  After a bit of prodding, it turns out the answer was that we can.  To get some help and momentum we reached out to Jack Daniels and Michelle Klinger from the BSides organization for help and support.  With that, we launched BSidesPHX in Feb of last year.  It was a great success, made some awesome badges and had roughly 160 people show up for our single day shin-diggy.

Shortly after that, we decided to move away from BSides.  I don't want to press issues, but we just felt as though our path was somewhat different.  What we share(d) with BSides is that the mission statement of our conference was:
"To provide the highest quality talks, in a vendor neutral format, for free."  
We took that mantra and mutated transformed into CactusCon. The name is a bit of a homage to the hilarity of the PLA, and also because we have cactii.  Lots of them.  Yesterday was the first of what we hope to be a long series of local events.

To begin with attendance was crazy.  Within the first hour of the conference we had gotten more people in than we did the entire total of last year.  I wasn't expecting the line of folks outside but uh, yah-- we had one.  Even Dave and Busters (our venue) commented on that.  I was personally blown away by this as we really didn't know what the response would be after having moved away from BSides.

The rest of the day went just awesome.  Our talks were solid, our keynote was fantastic (personally I think it was one of the best I've attended), our workshops went well, the lockpick village was well attended, and just everyone had nothing but great things to say.  I think most importantly: people connected, groups connected, and learning happened.  If individuals grow, then I say that Phoenix community itself is benefited. Win.

We wouldn't have been able to do this with some awesome support from our "sponsors."  I hate calling them that because it feels more like a partnership to me.  We run ideas through them, get some concepts of how to make this great for them and for us.  We work together-- what a crazy idea :-)

We also wouldn't have been able to do this with out Eric and Phil doing a 48+ hour badge making marathon at the local hackerspace (HeatSync Labs.)  The hackerspace community was just so awesome on this.  We needed help, and they went way above and beyond.  The fact that a place like this even exists is just amazing.  You can see the results of the badges here  (To save time on comments: the hole in the center is for a Jabra bluetooth earpiece that snaps into the badge.  You can sync it to your phone and take calls on the badge).

I'll end with saying that I have some very high-hopes for next year.  I am looking forward to collaborating with HeatSync and others in the local communities to pull off what I hope will be pretty awesome.

Thanks for letting me help with this again for another year.

Thursday, March 21, 2013

Conference Policies

Coming on the tail end of a debacle at BSidesSF and now more recently some things with Pycon... it has occurred to me that as a conference organizer we should likely have a 'policy' of sorts.  I will formalize this with the team post conference, but I am pretty sure I can summarize with a few key points below:
  1. No one should feel as though they are being harassed, so don't be a jackwagon
  2. This goes both ways, so how you handle things is just as important as what was actually said
  3. If someone/thing is bothering you, remove yourself and talk to a staff member-- ideally me
Everyone who comes to the conference should hopefully have a good time.  There are things in life you can't control, like stuff that comes out of other people's mouths.  There are things you can control, such as where you are sitting and your body which lets you move.  Sometimes leaving a situation is best, sometimes throwing jackwagons out is best.  I am not opposed to either response, depending on the circumstance.


Tuesday, March 5, 2013

Training developers like developers

I left professional software engineering about 3ish years ago to pursue a full-time job breaking software.  As a kid, I always had an interest in the topic and even as I grew into building software I was always security minded.  Before I had even taken the career leap, I was familiar with and led an OWASP chapter, read online articles and studied any book I could find on the subject.

One of the curious things, however, was that as a developer I found "security training" classes were horrible.  Predictably the format for every class was the same: work through authentication, authorization, CIA triad, SQL injection, encoding/xss issues, <insert security buzzwords here>, and whatever big ticket vulns dejour were out.  In the rare occasions that examples were offered in code, they were terrible.  They were often not in the language the team developed in, and even when they were-- the code was naive (often legacy) and didn't really take into consideration any of the actual important parts of writing code.

I always left feeling a bit let down.

Now... It is true that most testers have written scripts to automate an attack.  But in reality only a handful have ever built a product.  Even less have built a product that others depended on and couldn't crash.  Lesser still were in a position where they needed to make considerations about patterns and practices to make sure it'd scale technically and that other developers could work with it.  Security people are, by and large, simply not developers.

With out going into the implications of that professionally, what is interesting to call out is that it makes sense why training always seemed so off target.  How can you relate to people you don't relate to?  In my experience, trainers don't.  They try to turn developers into security people, because they know security.  I don't personally think that is okay.

I mean think about it, most classes are about becoming familiar with vulnerabilities-- but how many classes have you been to that focused on implementing solutions? How many have worked through an issue down to root cause of why code is vulnerable to manipulation and then showed you with design patterns how you might be able to solve it? How many bothered to show you how mature open source libraries solve security problems so you can glean ideas for your own project?  Hell-- how many classes have you been to that required you to write, build and test how secure your code is?

Perhaps this all just my experience, and that others have moved down this road before me.  I just feel like developers shouldn't be compelled to be security experts to write secure code.  They don't need to know every wiz-bang vulnerability on the market.  They need to know things like how to identify code smell, how to spot weaknesses in designs, and what practices are going to help improve code quality.

If classes focused around things developers are interested in-- like, uh-- development-- wouldn't that be a trip?

Tuesday, January 29, 2013

Goruck: Part 3 (Preparation)

It is funny to write about preparation-- since the first thing you learn at an actual event is how wrong you were.  But that doesn't mean I didn't try, and that I didn't get results out of being prepared.  The below are just some of the regular and irregular things I did to get ready.  I'll also add some reflection at the end.

1.) Crossfit.

Large portions of my training were at the gym.  I maintained a 4x a week training schedule, with a split focus on endurance and strength training.  This was the base of my training.

2.) Weekend Rucks

Every Sunday I'd head out with a buddy and we'd do about 6 miles up by his house.  I'd basically wear my weight for this, that is the 6 bricks & water.

3.) Special Rucks

I did some special trips-- including Camelback mountain.  I did this trip twice, once with a friend and about 90 pounds* in the rucksack.  We split carrying it on and off up and down echo canyon.  I also came back and did echo to cholla with 6 bricks & water.

The biggest trip I did was all of south mountain.  It was about 16 miles from one side to the other, which we covered in about 7 hours.  6 bricks, water, and some food.  Used this as a way to practice how I was going to handle my breaks.

I also went up north to do some cold weather gear checks.  These were useful for determining if the gear I had could hack it when it was cold.

4.) 6k

I ran a 6k somewhere in the midst of this.  Never ran more than 5k before, so I figured why not.  It worked out pretty well, I came in like 52nd out of 700+ people.

5.) Misc.

The last things I did included some bear crawls with ruck on & weight.  I also would take my ruck out during the week and do 1-3 miles with about 90 pounds on.


This training was very good for the endurance aspect of the event-- but didn't really prepare me for the demands of weight carrying.  In that sense, when I do this again, I am going to focus a bit more on carrying awkward heavy stuff on my shoulders, back, overhead and just holding it.  I think spending sometime being uncomfortable with heavy stuff would be good.

The other thing I'll spend some time with is accessing items quickly w/o putting the ruck down.  During the event, rucks can't touch the ground except on rare occasions.  Learning how to access stuff quickly to switch out items would be a good skill to have.

This doesn't mean I expect the next event to be similar to the last-- but I can see some areas to improve.  The beauty of each event is that each Cadre runs his own program, so you really don't have a clue what will happen next time.  No two events are the same.


I should also add a special thanks to my chiropractor.  I most likely wouldn't have been in any shape to do this with out him.

* my trainer told me the sandbag was 50 pounds, turns out it was closer to 85.  Hm...