4 ms·

Ask HN: How to monetize your ability to write secure code?

• api 11y ago
  It's tough because infosec is a terribly inefficient market. The vast majority of end users don't care about security until they are impacted by it, at which point they blame the vendor and scramble for a quick fix and then quickly go back to not caring. As a result, end users are rarely customers for security. (Or privacy, which really is just a form of security.) The vast majority of vendors do care something about security, but the knowledge and skill of actually understandings security is rare. Therefore most of the actual customers for security are ignorant customers who are looking for something that will make them feel secure. Ignorant customers tend to fall back on secondary indicators of status such as name and brand recognition and the opinions of those who are deemed experts in a given field. This makes security a bit of an in-club, where experts recommend each other through their expert advice. It also makes security a field where snake oil can get a lot of traction if it can correctly mimic these secondary signals or can piggyback on them. All fields with ignorant customer bases tend to be somewhat status-indicator-driven and anti-meritocratic. I'd advocate focusing your efforts more narrowly at breaking into this market on the positive (non-snake-oil) side. There are three ways I can think of to do this: (1) Try to get a job with a highly regarded security firm. (2) Look for the things that vendors use as secondary indicators such as certifications, and try to get at least one of those. Then use that to break into the market and start building a reputation. (3) Target a specific popular software product (e.g. OpenSSL, nginx, Apache, etc.) and identify a real vulnerability. Then "market" this vulnerability with a catchy name that will get you some recognition as its discoverer. Then use this as a credential. But be sure the thing you identify is real enough to impress those who do understand security or this could backfire a bit. For #3 I would highly suggest wading into the probably very shark infested waters of NodeJS and popular NPM packages. Node is the Hot New Thing and development has been progressing rapidly and chances are popular Node security and authentication packages are riddled with non-obvious holes. It's likely that you could identify a single insecure programming practice that is systematically encouraged by the nature of the JavaScript programming language and then bag dozens of vulnerabilities based on it by searching code bases for that pattern. "Eval" or any form of it has been a likely candidate in the past but that one is mostly common knowledge today, so you'll probably have to find a less obvious one. The core Node code might also be a fruitful place to look, since we (at my venture) recently had to delve into it a bit and it's a chthonic blob of C code if I ever saw one. Start with libuv, but keep some eye bleach and religious iconography handy.
  • some_furry 11y ago
    Thanks for the tip, I'm actually doing some work in the Node.js + Electron sphere right now, but that's under NDA.
• w_t_payne 11y ago
  Can you write tools that help others to write really secure code? I.e. something like a linter that helps to identify insecure code? Or maybe a design process or set of design restrictions that would help avoid insecure code? (I'm particularly interested in the state of safety / security for networked embedded sensor systems -- i.e. cameras or other sensors in mobile robotics, security/analytics etc... and I'm trying to produce a set of tools to help make the development of such tools safer and more secure as well as faster and more efficient).
• dsacco 11y ago
  Let me give you some advice, from the perspective of someone who runs a successful security firm. Have you worked as a consultant at one of the larger firms, like Optiv, Bishop Fox or NCC Group? What professional experience do you have? Have you found serious vulnerabilities and published them? Any bug bounties? Without a network to draw on it is very difficult to start your own practice. You need referrals, introductions and people to vouch for you. Failing that, you need to be "infosec famous" or very close to it (this is why so many people publish for publicity in the security world). My recommendation is that you join an established firm if you really have the technical skills. If you've already been at a serious firm for two or three years or so then you'll understand the business processes inherent to running a successful consultancy. Without understanding how that works you won't know how to leverage your skills and turn them into a reliable income on your own. Forget certifications. You don't need any to be successful if you can just demonstrate the ability to find vulnerabilities. The CISSP (as an example) can be helpful for a certain subset of clientele, but it's not useful enough to pour your energy into instead of e.g. getting CVEs on your rèsumè and establishing a network. Can you find every single vulnerability outlined in The Web Application Hacker's Handbook? How about the trickier ones that crop up in Black Hat presentations? It's not enough to be able to find CSRF or XSS in a bug bounty, you need to be reliable, consistent and thorough when working as a consultant. This is one of the reasons bug bounty participants are rarely qualified to join consultancies, even if they find vulnerabilities. They often lack the professional maturity to find more than a certain subset of vulnerabilities. Your first few clients will be the most difficult. Here is a rough outline of what you can do to get a pipeline of work: 1. Join a reputable security consultancy and develop your skills. Polish them from "I can find vulnerabilities" to "I can model a large software project for design flaws, implementation vulnerabilities and operational vulnerabilities, then thoroughly find everything" (within reason, given a finite testing timeline). Your track record for finding vulnerabilities must go from "more often than not" to "virtually always" for each application put in front of you. 2. Do independent security research. Subscribe to security alerts from large vendors. When a CVE is issued, check it out, try to reproduce the issue and learn from it. Start finding vulnerabilities just like it in widely used software frameworks and libraries. Build up a track record and a personal brand of security formidibility. 3. If you have done #1 or #2 already, or once you have, then leave and start your own practice. You won't be allowed to solicit your past employer's clients, but you can leverage your network. Talk to past colleagues and coworkers and put yourself out there. Try to subcontract out to various security firms (it's an open secret that most firms will do this if they have a surplus of work). 4. Aggressively pursue referrals for every single client you work with. Master the business side of running a consultancy. Consultants at large firms don't earn as much as successful independent consultants or founders because their margin is spread thinner. Conversely, your own practice will not have salespeople or account managers. It will be you and you alone. You must be able to communicate exceptionally well, maintain deadlines on your own, support a plethora of payment methods from clients (checks in mail, third parties, ACH transfers), survive under uncertain payment timelines (large clients love to languish accounts payable forever) and manage all your clients and sales pipelines on your own. Your technical ability must be exceptional, yet it will only be half of your ability to make a good income. I built what I have now by folllwing my own advice here and reading all of patio11 and tptacek's comments on consulting.