Re:How I went from programming to consulting (2012)
by baby on Monday December 25, 2017 @05:57AM
(#16003650)
I'm a cryptography/security consultant, here's the kind of things I do. Hope that helps :)
* I get on calls with potential clients to see if we can solve one of their needs. Their needs can be broad: auditing code or specific implementations; reading and vetting pages of protocol design; advising on third party products or libraries; documenting the risk of the latest X attack... Sometimes I can do it, sometimes someone else should do it, sometimes no-one can do it.
* If nobody can do it but it's an interesting problem and it's relatively reasonable to tackle I (or someone else) will spend X weeks researching the subject so that we can provide the service in the future. We've done this with ethereum smart contracts recently for example (it's been pretty fruitful and I'll be giving a talk at Black Hat Asia in a few months on the subject).
* When the job starts, I'll be talking to the client to make sure we're on the same page, see what kind of claims they want to make, what they're more scared of, etc... This helps a lot, but of course the client is not always right or not always aware of what might go wrong. Most often companies do not even have a threat model and have no idea what they should really defend against.
* Most of my engagement are remote, but depending on the field you might have to go on-site. In any case, you always try to be close to the client so that you can get responses relatively fast (consulting is expensive, you don't want to lose your time trying to find answers they can provide). (Unfortunately it is not always possible as some of them are really busy or just do not want to spend the time answering questions.)
* Whatever the type of job is, you always spend a few days internalizing everything you're reading or hearing (I call that drowning). You try to get an idea of what the product/protocol/solution/app is (if it's your first time working on it), you read papers or articles about it if you're rusty/missing some pieces, you go through the codebase and ask questions to see what is what and what is where.
* Then you dig in, you do what you're best at. In security/cryptography we try to break things, find gotchas, discover flaws :)
* Eventually, you need to provide some product to the client. It is often some document or a presentation (or both) of your findings. You want your client to understand what you did, like really, this is after all the product they're paying for. You also want to give out recommendations on how they can fix things, sometimes you will want to fix things yourself as well. It all depends on what you can do or what the client wants you to do (if you agree).
Anyway, these are my 2 cents. It's a field that mingles expertise with client satisfaction. You need to know something that can help one or several of their problems, and then you need to do your best to convey your explanations.
(I just wrote this huge comment because I felt inspired after reading a large 2000 day-old tptacek comment.)
* I get on calls with potential clients to see if we can solve one of their needs. Their needs can be broad: auditing code or specific implementations; reading and vetting pages of protocol design; advising on third party products or libraries; documenting the risk of the latest X attack... Sometimes I can do it, sometimes someone else should do it, sometimes no-one can do it.
* If nobody can do it but it's an interesting problem and it's relatively reasonable to tackle I (or someone else) will spend X weeks researching the subject so that we can provide the service in the future. We've done this with ethereum smart contracts recently for example (it's been pretty fruitful and I'll be giving a talk at Black Hat Asia in a few months on the subject).
* When the job starts, I'll be talking to the client to make sure we're on the same page, see what kind of claims they want to make, what they're more scared of, etc... This helps a lot, but of course the client is not always right or not always aware of what might go wrong. Most often companies do not even have a threat model and have no idea what they should really defend against.
* Most of my engagement are remote, but depending on the field you might have to go on-site. In any case, you always try to be close to the client so that you can get responses relatively fast (consulting is expensive, you don't want to lose your time trying to find answers they can provide). (Unfortunately it is not always possible as some of them are really busy or just do not want to spend the time answering questions.)
* Whatever the type of job is, you always spend a few days internalizing everything you're reading or hearing (I call that drowning). You try to get an idea of what the product/protocol/solution/app is (if it's your first time working on it), you read papers or articles about it if you're rusty/missing some pieces, you go through the codebase and ask questions to see what is what and what is where.
* Then you dig in, you do what you're best at. In security/cryptography we try to break things, find gotchas, discover flaws :)
* Eventually, you need to provide some product to the client. It is often some document or a presentation (or both) of your findings. You want your client to understand what you did, like really, this is after all the product they're paying for. You also want to give out recommendations on how they can fix things, sometimes you will want to fix things yourself as well. It all depends on what you can do or what the client wants you to do (if you agree).
Anyway, these are my 2 cents. It's a field that mingles expertise with client satisfaction. You need to know something that can help one or several of their problems, and then you need to do your best to convey your explanations.
(I just wrote this huge comment because I felt inspired after reading a large 2000 day-old tptacek comment.)