This is a personal blog. My other stuff: book | home page | Twitter | prepping | CNC robotics | electronics

August 26, 2016

So you want to work in security (but are too lazy to read Parisa's excellent essay)

If you have not seen it yet, Parisa Tabriz penned a lengthy and insightful post about her experiences on what it takes to succeed in the field of information security.

My own experiences align pretty closely with Parisa's take, so if you are making your first steps down this path, I strongly urge you to give her post a good read. But if I had to sum up my lessons from close to two decades in the industry, I would probably boil them down to four simple rules:

  1. Infosec is all about the mismatch between our intuition and the actual behavior of the systems we build. That makes it harmful to study the field as an abstract, isolated domain. To truly master it, dive into how computers work, then make a habit of asking yourself "okay, but what if assumption X does not hold true?" every step along the way.

  2. Security is a protoscience. Think of chemistry in the early 19th century: a glorious and messy thing, chock-full of colorful personalities, unsolved mysteries, and snake oil salesmen. You need passion and humility to survive. Those who think they have all the answers are a danger to themselves and to people who put their faith in them.

  3. People will trust you with their livelihoods, but will have no way to truly measure the quality of your work. Don't let them down: be painfully honest with yourself and work every single day to address your weaknesses. If you are not embarrassed by the views you held two years ago, you are getting complacent - and complacency kills.

  4. It will feel that way, but you are not smarter than software engineers. Walk in their shoes for a while: write your own code, show it to the world, and be humiliated by all the horrible mistakes you will inevitably make. It will make you better at your job - and will turn you into a better person, too.

8 comments:

  1. Regarding point 4, I'd say "write your own code under extreme time pressure".

    I know exactly what it is like to have a flaw in your code exposed. There's often an identifiable moment - on being shown the problem - when the user's actions and your assumptions part company, and you get that sense that the rules of the game you thought you were playing have been flouted.

    ReplyDelete
  2. "It will feel that way, but you are not smarter than software engineers"

    Maybe I misunderstood something fundamental here, but can you work in security and not be a software engineer? What are you then?

    ReplyDelete
    Replies
    1. Plenty of people in the field do not have a software engineering background and do not necessarily even know C++ from Java - especially if they go into compliance or management. I've met top infosec people from major banks or investment firms who didn't even know how HTTPS works.

      But more broadly, even people who are very technical usually don't end up designing or writing a ton of code. Their job revolves around poking holes in the designs and the implementation written by "regular" software engineers - basically trying to outsmart them for a living - so this breeds an unhealthy sense of superiority.

      Delete
    2. This is one thing I've learned when working for 2 years as single sec-op in an agile team of 100. If you work *with* developers you will get way further in the actual software security as compared to just setting policies and enforcing compliance. Software engineering is extremely complicated field now and there's no security policy that would cover each practical scenario. Only by working with developers you can understand the actual threat landscape and plan the controls to be sufficient but still reasonable - and being one of them is one of the best ways to achieve that, as you noted. Not to mention that the "just comply with standards" does not really work - even in financial sector you rarely have enough power to always mandate and enforce full compliance, for the reasons described above.

      Delete
  3. The rule number 4 should be the rule number 1, 2 and 3.

    ReplyDelete
  4. After read yours 4 points I got one question which programming language choice to learn and discovery? To be honest I am 2 year computing networking and I thing about choice some language I start thing between ruby and python ?

    ReplyDelete
    Replies
    1. I'm not sure it matters all that much. I'd start with something simple. The key is to try to figure out *why* the language works this way before moving on to something more abstract.

      My first language was Logo, then Sinclair Basic, then Pascal.

      Delete
    2. I'd say python. But then again I have never tried ruby. In the end though, as michal said above. The most important part is understanding the why. That makes it easy to apply that thought process to other languages. This is all just opinion though.

      Delete