Saturday, November 24, 2007

Good article about coding abstraction tools

This article from Hacking Hat is pretty good. It is a good reminder that there is no silver bullet (no shit) and that a tool that is trying to abstract a complex system has its limits. I would say that writing a program that abstracts a complex system can work but it can't be a generic off-the-shelf piece of software. Why is that though? I think one reason is that programming is purely a mental exercise and people never think the same way. Which means that the person implementing writing the off-the-shelf-software will make assumptions like "no one would ever do that" but in reality there is a good reason to do that for corner case X. You could make it so the off-the-shelf software could be configured but then it will be confusing and too complicated for most people to use and so the cycle continues.

Could there be a way to write a program that would hide a complicated system and make it work for the "common" user? Yes, I think so. I have seen some abstractions that work but they have all been custom software that works for one company.

I know other companies are trying to once again abstract code so that non-programmers can make programs. I just don't see this happening as programming is already pretty abstracted, I am sure there will be new abstractions but overall it will come down to people who will get it and the people who won't.

Well enough rambling I have work to do.

Saturday, November 17, 2007

The pros & cons to specialization

The last week or so I have been mulling over the implications of specialization in the IT area and also the implications in general. Before I go any further I want to make two things very clear:
1) This will be a long post.
2) I am not knocking specialization in general, I want my heart surgeon to be specialized, I don't care so much about the burger flipper at the local fast food chain.

However the majority of my professional experience (starting at the ripe old age of 16) has been in IT. As I am getting a little older now I am seeing the effects of people specializing. Do, I think it is good or bad that people specialize? Well I think it is good and bad when people specialize.

From what I can see here are the main reasons people specialize:
  • More money (bad reason, imho)
  • Forced to because of management (bad reason)
  • They are really interested in a certain area (good reason)
I think the reasons people do not specialize are:
  • They can't in their current position (i.e. small company)
  • They don't think they are "smart" enough (BS)
  • They are lazy
  • They would prefer to be a generalist
I am sure there are more reasons for each area but I will just stop now. So, what are the implications of specializing vs. not specializing? I really think it depends on the size of the company. At my previous employer you could not specialize, sure, you could just do programming but in order to best help the company it was better to be able to wear multiple hats (support, network administration, programming, security, etc...). The company was small though and there was a total of 7 IT people which really is not many for a 400 person company with 20+ internal applications.

At my current employer the company is huge and their is a management push to specialize and then broaden your impact on the company. This is fine and good until you sit and think about it. If the majority of people are specialized in one skill how will they be able to see problems that are outside of their specialty? What happens when almost everyone is a specialist? Who will be there to take a macro-view of the whole situation and say "hey, what the fuck are you guys doing this blows?"

Isn't there a need for specialist in IT? Yes, there is. Does everyone need to be? No, I think the majority of people do not need to be specialist but here in lies the rub. It is basic economics that if you are a specialist the supply of the same specialist will be low and you can charge more. Which means if you want to make more money you need to specialize. See the problem? The ability to get the same pay but do a good job being a generalist is not there. That to me is the key issue. Why can't IT workers be paid just as well for being there year after year learning product X better and doing solid work (not just "I get the job done")? One thing I have thought about is that if more and more people become specialized the generalist is now a specialist :).

I can also hear a few people saying "Mike, you are in application security aren't you specialized?" Umm, kind of I guess but not really. On any given day I will have to put on my project management hat, my developer hat, my security hat, my database developer hat, my usability hat, etc... I have a wide body of interests in IT so if you wish to debate with me on if I am specialist lets go get a beer and we can debate, I will even buy the first round :).

Yes, I am biased towards being a generalist but I also see the value of people who are specialized. If I had some database performance work I want someone who knows how the specific database's indexer works, what gets pre-compiled and other tricks for making database operations as quick as possible. I also know the power of someone who can read assembly like it is a fiction. But in the same lines I have seen the use of someone who has basic knowledge of all areas and can pull them together to create a rather interesting idea.

With everything being said I would say that it seems like when people are in a larger organization they tend to specialize and try not to take a holistic view. I think that is the wrong way to go because it will create disconnected systems and duplicated work. It should rather be that the majority of people are generalist and when they need someone who is specialized they contact that person. What about pay though? Well that is a challenging thing which I think could be a whole post on its own :).

Well back to finishing off my latte.

Tuesday, November 13, 2007

Instruments the built-in OSX hacking tool

Apple recently released their new operating system, Leopard. There are a few cool features to this OS but the one I am most excited about is a new development tool called Instruments. Instruments is a GUI tool and wrapper around a port of DTrace. What does this give us? Basically DTrace is a library that allows you to query kernel level events. For me I have been dying for something like FileMon or ProcessMon for the OSX platform now I have it but it is on steroids. Needless to say this made my day. What does Instruments look like? Kind of like this..



The above screen shot is showing a sample run looking at the file i/o of all processes on my system (looks like quicksilver is doing a scan). It is also possible to specify a specific process or to launch a new program you wish to monitor. So, what you say? You could see the file i/o of any process with the previous version of OSX with fsLogger (although it was kind of ugly, imho). Well Instruments is far more extendable (a later blog post) and there are a lot of default libraries that can be used.

There are 27 default "instruments" in the library that can be used. These range from monitoring network traffic, locks, i/o processes, memory usage and even UI recording. There are many libraries and some of them will only work for a single process while others will work for monitoring all processes. Since there are so many instruments it is a blog post in its own explaining all the different instruments.

Other things that are useful for Instruments is that you can do multiple runs and they will be shown side-by-side. Also, you can save your runs for later replaying or investigation.

So, why do I say this is a hacking tool and not a development tool? Because a lot of hacking (in my mind) is figuring out how programs work, how the person's mind works who wrote it and then finding the chinks in their thoughts or their laziness. Many development tools can be re-purposed for attacking the programs that were written with the same tools because when we get down to it we are just doing some weird ass debugging on the products :). Being able to see what files are being written/read from a program shows us some of the attack surface. But being able to view how the memory and other system resources from the program will show us even more of the attack surface. On top of that it gives anyone better insight into how a program or system resource works. Which means that Instruments is a development tool but I see it as being really really useful for "security research."

I will be posting a few more posts on this tool. I am not sure how many posts yet as I am still learning about this tool and OSX in general but if you liked this post stay tuned :).

Labels: , , ,

Thursday, November 08, 2007

Knowing When to Part Ways

Today is the first day I had to end a job with a client because I knew it wouldn't be a good fit. Surprisingly it was easier than I thought it would be :). Why am I writing this blog post if not to be self-congratulatory? Because I think it is one of the toughest things to do for anyone who handles clients. If you think about it you are walking away from cash. As a consultant/business you can never be sure if/when everything will dry up.

However, what would have been the downsides if I had taken on this client?
  • A strained relationship making both sides annoyed, angry, etc...
  • Potential legal issues if it got really out of hand (very doubtful in this case)
  • No payment from an unfinished job
  • The client would have had a negative view of me and would have probably not told other people about me
  • My work for my other clients could have gone down the toilet losing other revenue
  • Loss of trust by the person who recommended me
I am sure there are more but those are the ones I can think of off the top of my head. So what are the upsides? A little bit of cash and one more client to take care of. In my head since I knew it would have been strained relationship because our personalities conflicted a lot it was a better idea to lose the money. I know I can make up for the money so I figured that shouldn't be a huge factor.

But this doesn't apply to just client relationships. I think this applies to all business type of relationships that have to be done. Once people get busy there needs to be some filter to figure out what takes priority and what projects/tasks a person should take on and others that should be turned away because you know you are not the best person to do the job.

My question to my readers, what things would you turn away?
Gmail + Firefox Extension Detection

This morning I check one of my gmail accounts like normal. However, today it is a little different at the top I see the below notification.


Now I guess it is nice that they let me know of the performance issue and they are just trying to make the user experience the best it can be. However, there are two "bad" things that come from this in my mind.
1) Google is looking at the extensions that are installed on my browser, what else are they looking at?
2) With this idea in mind I can think of the following scenario. A "security researcher" finds a zero-day in Firebug (this has happened before) and does not disclose it. They setup a site using the same code as Gmail but instead of posting a nice message exploits the zero-day and takes over the people's browser.

I am not the first person to think of this. But I was just reminded of it this morning. Thankfully I don't keep my Firebug enabled but I am sure quite a few people do.

I guess I will have to add this on to my research list.