Here part three of a three part conversation with Brian Chess (Part 1, Part 2), the last part of the conversation, Brian closed with the following regarding how to focus software security efforts: "In any case, the right answer is NOT trying to risk-rank your apps and chew through them one at a time until the universe cools."
GP: So if the right answer is NOT to risk rank and cycle through, and I agree, what I think this also is saying is that the static analysis *team* should be building up real skills; because they are going deeper into a subset of apps. Beyond the wonders of the tools and process, I have come to think that success in technology projects is about people and teams. What factors have you observed that make people and teams succeed in software security over the long haul?
BC: I'll tell you what's worked for me.
For people:
Being smart is important, but if you know how to program a computer, you're smart enough. Now you have to put in a lot of hours. A LOT OF HOURS. Do something you really love because it's easier to sink all that time into it.
If you're like me and you'd rather be sitting in front of a keyboard instead of dealing with people, figure out how you're going to get out and share your ideas. Feedback makes a world of difference.
Ever wonder why so many programmers are so bad at security? Part of the problem is that most of them don't know they're bad. Generally speaking, people are bad at assessing their own strengths and weaknesses (read this). That means you need to seek objective measures of your work. If it doesn't sting sometimes, you're not doing it right.
I like most of what Austin Kleon has to say in his How to Steal Like an Artist talk. He uses the word “artist” a lot. Most of the artists out there haven’t figured out just how much they have in common with engineers. Shhh.
For teams:
About a year after we hired the third round of people at Fortify, I wondered if we'd really screwed up. They hadn't come up the curve the way the first two rounds had. I thought maybe we'd gotten lax with our interview process, or maybe we had just gotten really lucky in the first two rounds, and the third round was payback. Eventually I figured out that what had gone right with the first two rounds is that we'd invested an incredible amount of time with them. We'd worked shoulder-to-shoulder in a cramped little office. We'd had lunch together almost every day for more than a year. By the time round three arrived, all the old hands were either flying around speaking and visiting with customers (that was me), or they were desperately trying to type in all of the code people like me were saying absolutely must exist as of yesterday. As a consequence, the new crowd didn't get anything close to the same amount of attention.
Moral to the story: building a great team takes a lot of interaction. Work with people you like. If you don't, that interaction will never happen, and you'll never form a good team. But here's what makes interaction a really tough pursuit: the work we do requires a lot of concentration over an extended period, so everyone needs a quiet place to work. There's tension between the need for interaction and the need for solitude. A great team figures out how to get both.
The modern trend is towards distributed teams. There is an unquestionable advantage to being able to pull people from any geography, but the ramp to being a good team is much longer because it's hard to accumulate the necessary amount of interaction.
Regarding hiring for software security assurance jobs, look for software skills first and security skills second. Security is not easy, but software is a bitch.
Comments