Wednesday, October 31, 2007

Knowing How to Write Code != Developer


I have had this conversation a few times in the past week or two. A person who knows how to write code isn't alway a developer. I would say far from it. Few people are actually developers instead of code monkeys. Am I a developer? Hmmm... I might have been in a past life, now I am just a confused geek. In the security circles I seem to have this conversation more since they say they know development when in reality they just know how to write code. Don't get me wrong there are people in all areas that do know development, but from my scant exposure I would say they are in the minority.

Before I continue this post let me define what I think a developer is. A developer to me is a programmer who writes code but keeps the following things in his mind while coding: maintainability, how to minimize the amount of code he writes, good comments, clear interactions, clean interfaces, how the code will manifest the business decisions, when he is just gold-plating the product instead of getting what is needed done, not trying to do premature optimization because he knows that it is foolish, how the customer will use the product and of course how the source could be attacked or broken (on purpose or not). To me a developer is not just a code-slinger but someone who has a mix of skills from tester, project manager, programming, business analyst and most importantly an interpreter between humans and computers.

This is far different than someone who can just write a program and get it to run :). Now I might be full of shit (more than likely) but this is how I view the difference. The code-slingers might say they can do this, which is true it is stuff that can be done it isn't rocket science no part of IT is. As, I have said about technology the hardest part is the human factor of IT. Technologies can be learned easily but humans are confusing as all hell :).

To finish off this post my main point is that I think developers have a unique set of skills and should be highly valued. However, I don't think many people have the same definition as I do. I do know some do but not everyone. I do wish that companies would realize the difference between the skill sets in some programmers/developers to give them the rewards that justify their work and skills they have learned.

Saturday, October 27, 2007

Uh-oh First Crash in Leopard


I was using my laptop at my favorite coffee shop and it froze, doh! This is my first crash since I have loaded Leopard and it didn't even take 24 hours :). Granted I wasn't doing anything crazy so I was lucky. What is my point?

Well I looked at the error and it was this:

'panic(cpu 0 caller 0x0039CDE0): "m_free: freeing an already freed mbuf"@/SourceCache/xnu/xnu-1228/bsd/kern/uipc_mbuf.c:2742'

Nothing crazy right? Wrong! This is called a double free bug and it can be a security vulnerability. From my limited understanding of these types of bugs it is considered vulnerable until proven other wise. I will have to look into it more when I have time (not sure when that will be).

Details about Double Free

Initial Impression of Leopard


Just loaded Leopard, so far I like it. Some of the features have been in Linux for a bit (e.g. spaces) but overall very impressive. I like stacks the little I have played with it and it looks like .Mail is in the running for replacing Thunderbird for my main mail client.

More later after I have played with it some more :).

Wednesday, October 24, 2007

Internet Explorer and one way to make it better


Any serious web developer uses Firefox as their main browser for development, period. Sure, you can argue with me, but, I know this is the popular view and I certainly agree with it. Why is Firefox so good for development? Is it the cool logo? The Open Source idealism? Fuck no! It is the freaking plug-ins. There are so many good ones for Firefox and the browser renders pages with very few quirks, so, as a dev you are shooting yourself in the foot if you use anything else. This can also be said for web application security auditing, especially when you are black boxing (i.e. hacking). But this post is not to list out all the virtues of Firefox it is to talk about the black scourge that is Internet Explorer. There are a few reasons that IE blows.
1) Horrible rendering with many browser bugs (HTML & JavaScript)
2) Very limited development tools
3) Hard to write plug-ins (COM come on!)
4) Not OS-independent (alright, that is a stretch)

At my current day gig I have to use IE, so, I have to deal. But it has me thinking. It can't be that hard to write a IE plug-in that takes the major FireFox plug-ins and make them work under IE. It is something I have been mulling over for the past month.

I hope to take on this task in the next month or two and when I do expect some blog posts on the journey and hopefully a plug-in that will allow for this.

Friday, October 19, 2007

The Power of Lists


For the past few years I have used lists to keep myself semi-organized on what I need and want to get done. I find them very useful and motivating. From what I know (which is very little) about the GTD process it also heavily relies on lists. For me the most useful one I have is this one called "things_todo_today.txt" it sits at the bottom right corner of my desktop. One of the last things I do before I drift off to sleep is write down the things I want to accomplish the next day. Some are general and some are very specific. I also do this for my day job. Why do I do this? Well for two good reasons:
1) My brain leaks like a sieve and I can't always remember what I want or need to get done.
2) I find it motivating when I get to move an item on my list from "todo" to "finished."

So, what does a daily list look like for me? Kind of like....

--== Things to do today ==--
- Work on product X
- Day Job
- Kitty Litter
- Dinner
- Work on client Y
- Work on client Z
- Follow-up with Bob

--== Things Finished ==--


Well that is what it looks like at the start of the day :). The goal is to always have everything on the list in the "finished" area by time I write the new one. Do I accomplish that goal every day? Nope. Do I get close? Yep! Other things come up and I adjust throughout the day. Will this work for everyone? I doubt it. I am sure some people would hate to do this and/or not maintain the list or be over-zealous and put 50 things on the list. There needs to be a good balance between getting stuff done and overloading yourself. If you put too much on your daily plate you will just feel crappy, which is never fun.

Back to work, I go.

Wednesday, October 17, 2007

Oh the kids these days


Tonight I found out one my girlfriend's little brothers setup a web proxy on my server. Needless to say I told him to get it off of there, something about an open proxy on a server connected to a nice fat connection just settles wrong with me. Granted when I was 15 I would have been jumping up and down with glee. I understand why he did it but boy have the kids changed! When I was growing up it would have been a big deal if someone found some pr0n in my room, now a days it is more worrisome if I know they are hacking.

There is nothing wrong with kids hacking, shit I did it as a youth. But, the laws have changed and the underground culture is a tad bit different. Am I hypocrite for telling him to knock it off? I feel a little bit like it but at the same time I don't. When I was doing it we had our own servers or found random ones. With that in my mind I don't feel too bad, that and knowing my parents had no clue what I was doing in my room so they couldn't tell me to knock it off :).

Tuesday, October 09, 2007

My Issues with Application Security


Before I begin this post let me preface it with saying I believe in Application Security, however, I have some major issues with it in its current incarnation.

First off what is application security? Application security is finding flaws in the design and implementation of software written for all computer devices. This is a huge field and one that I find interesting because it boils down to a cat and mouse game. You as a the security tester need to know more than the developer and other attackers to find flaws before them.

So what are the issues? I think the main issues are:

  • Relationships between security researchers and software vendors

  • The FUD that is generated by security vendors

  • The immaturity of the industry

  • The direct conflict between good software and good security

  • Very few holistic views are taken with software



The first two issues have been touched on by many people and I think are getting better. If you want to know more search on "full-disclosure", "RFP", "security bullshit", etc... I am really not wise enough to speak on these things so I am leaving it to the brains of the world.

However, I think I can speak on the last three as it is something I have spent time thinking on and analyzing what people do. Granted I am sure there are other people who have been looking into these issues longer than I.

The immaturity of the industry


Application security really has only been around for roughly 15 years which isn't that long in the whole scheme of things. There are many people who know a lot of information about computers and how those things can be used maliciously which is cool from a geeky stand point. However, I often hear people say why isn't company "X" finding all the security bugs. Well why isn't the same company "X" finding all the functionality bugs? Because it is impossible. However, if you look into functionality testing they have planned ways of testing most functionality to minimize the number of bugs being shipped. Why doesn't security have this? Currently from what I have seen there are a few common ways of testing for security things:
1) Use an automated scanning tool
2) Do code reviews
3) Do a penetration test
4) Focus on specific bugs (i.e. focus on XSS, buffer overflows)
5) A combination of all of these

Now, doing a combination is the best of the choices from this list. However, it is missing two main issues. Which is testing is still ad-hoc and two it doesn't get at the root of the problem why can't we make tools that make it harder for devs to make simple mistakes that cause stupid shit like XSS. Very few security testers I have met have done things like corner cases, boundary testing, equivalence class testing, etc... I guess overall most security testers look for the big bug and sometimes rush through the "boring" stuff. On top of that I find most security testers lack the majority of skills that the true hackers have (great coding skills, love of deep technical knowledge and the most important skill a very malicious view of the world).

The direct conflict between good software and good security


There is a direct conflict between easily used software and good security. Why? Because a lot of security involves putting up road-blocks for attackers and programs are not smart enough to figure out if the user is dumb or malicious :). I am guility of offering a software solution to a security problem and in my mind I am thinking "god, this will blow ass for normal users." For a great example look at Vista sure it might be more secure than other OSes but the pain threshold of this OS is very high. Another example is OpenBSD which is pretty secure by default. Is it easier to setup than a Fedora, CentOS, Ubuntu linux install? Nope it is tougher. This means that the business needs to weigh the security implications against the usability of the product.

Now, there is a caveat to all of this. There are two types of security bugs in my mind. There are the low-hanging fruit like: XSS, Sql Injection, CSRF, Buffer overflows, etc.. that boil down to poor input validation and output encoding. Then there are the nasty bugs that usually stem from very poor design decisions. This point only really affects the design level issues. If there is validation or encoding issues those are just bugs, it just takes someone who is malicious of how to spin it to their advantage to take control ;).

Very few holistic views are taken with software


This I believe is an issue with the majority of software developed and not just security. It is rare to find a developer who has read up on usability, user-centered design, understands security, knows about internationalization, business & business decisions, psychology, how to write good copy, project management, testing and how to write decently maintainable code and probably 100 other things I am forgetting to mention ;). This is because just by itself writing good code is fucking hard. I don't mean it is mentally challenging to write the code but making sure you cover all the corner cases and it is well documented and has decent test cases covering the code it takes a lot of grunt work that most people are just too lazy to do (yes I am rather pessimistic :D). But this is something that I think is at the center of new methodologies like agile, ALT.Net, etc.. More of the newcomer developers and smaller businesses do cover a lot of these issues because they "get it." It seems that the bigger companies don't currently get this though, probably because they have a lot of older grumpier people who don't want to change and normal grunts who don't believe all of these things fit into their job description. So, what impact does this have on application security? Quite a bit. If someone understood all of these things some of the security issues I believe would be gone. Good usability re-enforces good security, good coding practices minimizes a lot of the low hanging fruit security bugs, etc..

Well I guess my main point in this article is to express some (although not all) of my frustrations with the current state of application security. I think it will be interesting to look back in 5-10 years if I am still in the industry and see what problems still exist and what new ones there are!

Sunday, October 07, 2007

Different experiences starting at the same company


Everyone who reads this blog knows I work at Microsoft, so, I will speak about something that I find very interesting. A guy I know who is pretty cool although I have only known him for a few months, Mark Curphey wrote a blog post about his first week at the borg that can be found here. His experience sounds awesome, what was mine? Quite the opposite, IMHO. My first week was boring. Was it the team? Was it me? Was it the department we went to? Was it the levels we got hired at(He is a director, I am the lowest level of tester possible)? Was it the fact that I am an unknown and he is very well known? I think it is a mixture of all of it. My first week and my time there since has been filled frustration which I won't fully go into.

I find this very interesting because people's first impressions with a job will go a lot further then the next few months after the first week. Which is probably why I have had a little bit of my frustration. I also acknowledge that my life goals are probably a lot different than Mark's I will eventually be a business owner and run my business as my primary gig. However, Mark has always worked for someone even if he has been a C-level exec, which is not something to take lightly (note I don't know Mark's life goals so I can't say what his are). I think it takes a different person to run a business and start it from scratch then it is to be an executive. Some may say being an employee in as big of a company as MS you need to act like your job is your own business and you need to market yourself to get ahead. Sadly, I agree with that statement and am starting to do that at MS just for practice and as an experiment. Now this isn't a dig to Mark because what he has done and is doing is awesome and helps the security community and the majority of the population would love to be in his shoes. What I find interesting is just our experiences at Microsoft. I am sure when I get to meet with Mark in person and have a few beers we will have an interesting conversation about this, but time will tell :P.

Well back to my businesses (yes plural).

Wednesday, October 03, 2007

You can tell how long someone has been in the computer industry when...


You can tell how long someone has been in the computer industry based on the examples they give for major fuck-ups.

For example we will pick on Microsoft. Someone who has been around since the early 90s will more than likely choose Bob, someone a little newer probably around the late 1990s would mention Clippy, a person that started around 2000 will mention Windows ME and probably newer people will focus on Vista :P.

I know this isn't true all the time but it is a pattern I have noticed and it made me smile.

Monday, October 01, 2007

Devs vs. PMs let the rumble begin!


Many people are familiar with the role of Project Manager (PM) and few - well everyone who reads this blog - know what a software developer (dev) is. These two roles clash often. I was talking with my Uncle in New York earlier today about PMs and Devs and it got me thinking. There are a few reasons the PM role came around:

1) To manage multiple workers and their tasks on a large project
2) To handle client interaction so the grumpy developer didn't pull out his nerf gun and shoot the client
3) To write specs and be the filter between the dev and client, allowing for the the devs to focus on their work and not dealing with the people who actually pay.

I am sure there are other reasons but three is a nice number. Now I understand the first option and it makes sense from a business perspective. The other two options, however, should be judged on a case by case basis, imho. Some developers actually do enjoy talking to clients/customers/end-users and don't like the filter of going through another person. While other developers should be kept locked in their room. When dealing with piece work that is charged at a flat rate it is good for someone to get in there and create the specification and own that document. Does that mean a dev should never talk to the client? Nope, it means the effort of communication just got more tedious. However, the downfall to all of this is most people suck arse at communicating and making sure everyone is in the loop. So, inside of this rambling post there is a point.

The point is this: the stereo-type of PMs needing to make sure the devs behave is not always needed. However, most people are too lazy and/or busy to evaluate the individual and what the Dev PM relation should be.

Where do I fit into this spectrum of people? Well I can and do, fulfill a PM role when working with clients. Am I perfect? Heck no I can be a moody SOB a lot of days, have I gotten better as I am getting older, yep. Do I have another 10,000 miles to go in this journey, you betcha!

Back to work....