4 ms·

1) Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE. This is how to not lose your mind when constantly addressing

1) Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE. This is how to not lose your mind when constantly addressing sec issues that others (devs) are entirely responsible for fixing. 2) Department of No doesn't have to be a thing, it just takes some emotional intelligence and pragmatism. 'Always saying no' is as much the fault of the sec eng as it is the system. If you have the will power and general positive mindset, it's more than easy to go through a sec career without getting angry. It just requires not default No, and .... 3) Understand people want to do a good job. If you tell them they're doing a shitty job, they'll tell you to fuck off. If you (sarcasm font) admire what they're doing, and have some stuff that can get added to build an even better product, people are surprisingly amenable to working with you. It seems like 70% of sec folks think their job is to say No, and as a result never get there. 4) This was a huge lesson for me that made me understand the field: to be successful in sec, you must learn that your personal risk tolerance will not always equal the enterprise's risk tolerance. Making money, in a digital field, is an inherently risk-on undertaking. It's crucial to know what to not escalate beyond your team, what to not cause a fuss about, what is just a known risk that will continue to exist, and then have clear requirements for what risk you will escalate and shake cages about. It seems like all of these sec rants boil down to seeing the system and being unwilling to work within it, vs. seeing the system, accepting it, and figuring out how best to navigate it, and what tools and personal skill sets I'll really have to maximize to succeed in it.

authoritarian 7y ago
>Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE I think this depends on what kind of infosec work you plan to be doing. I have been a security engineer for the past 4ish years, and while I do have some programming/scripting skills it certainly isn't at the level of a SWE. Most of the projects I work on I end up doing pentesting, risk assessments, remediation for compliance, assisting with policies/procedures, and/or security focused devops work. It would definitely be useful if I could program at the level of an SWE, and I do plan to continue to develop my skills, but I wouldn't say that to be in infosec you have to learn to code at the level of an SWE. I agree with all your other points
- dogman144 7y ago
  There's obviously a lot of mileage left still to be 'good at a scripting language' but not a SWE. Frankly I'm not there yet but getting there. I see getting spun up to SWE-levels of programming as a mix of a intelligently defensive career move as shift-left becomes more of a thing in sec and SDN is "replacing" traditional networking, it gives you a ton of bona fides with devs as you can code your own solution or at least work 1-1 with a dev as a lot of problems originate in their area ("I'm asking you to do this work, but I'll do it with you all the way" counts for a lot), and then lastly ensures you can't get wool pulled over your eyes by devs/etc. Sec and Ops have always had a pretty common language, and for a really good reason. As everything gets so code-heavy (see: SREs in Ops land), seems like Sec and Dev need that meshing.
pm90 7y ago
I think you make some excellent points. One side effect of working with Agile instead of waterfall systems is that changes are being pushed out to production at a staggering pace, the job of the Infosec person today requires some understanding of the fundamentals of SWE. Hilariously, I see this in my own organization, which has a Security department staffed by old-school "security" folks who have very very little idea about what our systems actually do, what kind of crypto methods they use to secure etc... and there is one person who does and she is the only person who gets anything done.
Thriptic 7y ago
I agree with everything you said. To expand on point 3, when you are pitching a security change, know your audience. Most people hear security change and they think another inconvenient pain in the ass that I'm going to have to deal with. That changes if you can show them benefits to people or to the business that are not security related. For example, traditional approach: Boss: You are advocating spending a lot of money on a configuration management solution, why? Sec: Well it can help prevent heterogeneity in our environment which can lead to different versions of software being run, some of which may be old and buggy and therefore exploitable. Dev team: So now we need to do change management meetings and institute even more controls? No, this will slow us down! Ops: Sigh, another fad system we will have to support, learn, and test. Boss: This seems like a lot of money and inconvenience for a theoretical problem, no. Better approach: Boss: You are advocating spending a lot of money on a configuration management solution, why? Sec: Because it's a win for the business. Our Dev teams can avoid dependency hell and be confident that code they develop on their machines is going to work in production because our production environment will mirror the development environment. This will let them ship faster and spend more time doing real work. Ops will be able to scale much faster and spend less time dealing with configuration issues. Imagine being able to develop a config and spin up 50 servers with it at the same time while you sit back and sip a soda! No more fixing damaged boxes, just replace them! No more fighting with the dev teams! Oh yeah, we also get a security benefit for free while making our lives easier as we won't have to deal with heterogeneous software running on our boxes which presents a security vuln. The ROI for the business will be large. Everyone: wow sounds great, let's do it!
- dogman144 7y ago
  Yeah nailing it. If a sec eng can master the departmental wants of ops/dev/sales/etc., and figure out how (or just a way, even a vague one) how security enables those wants, and then mix in that MBA speak, the job is so much easier.
parliament32 7y ago
>Department of No doesn't have to be a thing This is the key. Mastering "yes, but" will not only make people like you more, but will also change your personal outlook on situations and avoid burnout like the author. Even if you don't realize it, there's a very different emotional impact between "I had to say no to that proposal" vs "I presented the options for that proposal, and they decided to not go through with it". For lack of a better term, it's no longer "your fault". From the article: >No, we can't do that. No, it doesn't support that. No, the vendor doesn't allow for that. No, you don't have the right license. No, no, no. Isn't the point of technology to enable businesses? So why am I saying no so often? Because you're shit at communicating. Yes, we can do that, but you'll need to (pay for X || do Y || get Z to do this other thing). Yes, but your current vendor doesn't support that, although vendor Q does. Yes, but your current license doesn't do that, you'll need this license instead. The joke is once you present the "effort" required to do what they want to do, 80% of the time they'll give up on it anyways. It's the same end result. But you didn't have to say no!
Kalium 7y ago
I've worked in a shop where InfoSec tried to be the Department of Yes. They were very effective at that - they basically never said "No" to anything. The downside was that they weren't actually able to say "No" to the things that they really needed to be able to change. A lack of accountability for decisions meant that people could ignore InfoSec consequence-free. All told, I've learned that security needs to have the ability to say "No" and the organizational backing to make it stick. It's the implicit threat that makes other groups play ball. I've had at best mixed results with covering people with positivity and admiration in an effort to get them to fix things. It's often easy enough when it's something really small that looks easy and understandable. When you've got a whole architecture predicated on everything accessing everything unchecked, suggesting that maybe this absolutely amazing architecture could be even better with a tiny bit of TLS and authentication is unlikely to get you anywhere.
- dogman144 7y ago
  That's my fault for not clarifying, good point. Not being Dept No != Being Dept Yes. It's really not about fluffing them up with admiration (they'll see through that soon enough). It's more about figuring out what the overarching mission of the enterprise is, that in turn dev, ops, sales, hr/accounting, biz dev, and sec all have to work towards (and largely want to, under the frame of doing a good job, and assuming it's not a toxic, failing workplace), and explaining for security under that premise. This gets you a (1) way to couch sec in the 'doing a good job' language, and (2) gives you firepower with mgmt if you're told to fuck off by XYZ dev, as ultimately: business mission wins. So make your sec = business mission. Avoiding 'No' is about approaching how you sell, implement and get buy-in for lasting behavior/process change. It takes a tremendous amount of work that goes beyond a hacker news comment box, but leadership + organizational awareness are pretty key in that regard.
agumonkey 7y ago
3) makes me believe even deeper that most work life is about satisfying other people. You feel motivated because you feel capable of making X other persons happy.

authoritarian 7y ago

>Increasingly, if you want to be in infosec, you have to learn how to code on the level of a SWE I think this depends on what kind of infosec work you plan to be doing. I have been a security engineer for the past 4ish years, and while I do have some programming/scripting skills it certainly isn't at the level of a SWE. Most of the projects I work on I end up doing pentesting, risk assessments, remediation for compliance, assisting with policies/procedures, and/or security focused devops work. It would definitely be useful if I could program at the level of an SWE, and I do plan to continue to develop my skills, but I wouldn't say that to be in infosec you have to learn to code at the level of an SWE. I agree with all your other points

dogman144 7y ago
There's obviously a lot of mileage left still to be 'good at a scripting language' but not a SWE. Frankly I'm not there yet but getting there. I see getting spun up to SWE-levels of programming as a mix of a intelligently defensive career move as shift-left becomes more of a thing in sec and SDN is "replacing" traditional networking, it gives you a ton of bona fides with devs as you can code your own solution or at least work 1-1 with a dev as a lot of problems originate in their area ("I'm asking you to do this work, but I'll do it with you all the way" counts for a lot), and then lastly ensures you can't get wool pulled over your eyes by devs/etc. Sec and Ops have always had a pretty common language, and for a really good reason. As everything gets so code-heavy (see: SREs in Ops land), seems like Sec and Dev need that meshing.

pm90 7y ago

I think you make some excellent points. One side effect of working with Agile instead of waterfall systems is that changes are being pushed out to production at a staggering pace, the job of the Infosec person today requires some understanding of the fundamentals of SWE. Hilariously, I see this in my own organization, which has a Security department staffed by old-school "security" folks who have very very little idea about what our systems actually do, what kind of crypto methods they use to secure etc... and there is one person who does and she is the only person who gets anything done.

Thriptic 7y ago

I agree with everything you said. To expand on point 3, when you are pitching a security change, know your audience. Most people hear security change and they think another inconvenient pain in the ass that I'm going to have to deal with. That changes if you can show them benefits to people or to the business that are not security related. For example, traditional approach: Boss: You are advocating spending a lot of money on a configuration management solution, why? Sec: Well it can help prevent heterogeneity in our environment which can lead to different versions of software being run, some of which may be old and buggy and therefore exploitable. Dev team: So now we need to do change management meetings and institute even more controls? No, this will slow us down! Ops: Sigh, another fad system we will have to support, learn, and test. Boss: This seems like a lot of money and inconvenience for a theoretical problem, no. Better approach: Boss: You are advocating spending a lot of money on a configuration management solution, why? Sec: Because it's a win for the business. Our Dev teams can avoid dependency hell and be confident that code they develop on their machines is going to work in production because our production environment will mirror the development environment. This will let them ship faster and spend more time doing real work. Ops will be able to scale much faster and spend less time dealing with configuration issues. Imagine being able to develop a config and spin up 50 servers with it at the same time while you sit back and sip a soda! No more fixing damaged boxes, just replace them! No more fighting with the dev teams! Oh yeah, we also get a security benefit for free while making our lives easier as we won't have to deal with heterogeneous software running on our boxes which presents a security vuln. The ROI for the business will be large. Everyone: wow sounds great, let's do it!

dogman144 7y ago
Yeah nailing it. If a sec eng can master the departmental wants of ops/dev/sales/etc., and figure out how (or just a way, even a vague one) how security enables those wants, and then mix in that MBA speak, the job is so much easier.

parliament32 7y ago

>Department of No doesn't have to be a thing This is the key. Mastering "yes, but" will not only make people like you more, but will also change your personal outlook on situations and avoid burnout like the author. Even if you don't realize it, there's a very different emotional impact between "I had to say no to that proposal" vs "I presented the options for that proposal, and they decided to not go through with it". For lack of a better term, it's no longer "your fault". From the article: >No, we can't do that. No, it doesn't support that. No, the vendor doesn't allow for that. No, you don't have the right license. No, no, no. Isn't the point of technology to enable businesses? So why am I saying no so often? Because you're shit at communicating. Yes, we can do that, but you'll need to (pay for X || do Y || get Z to do this other thing). Yes, but your current vendor doesn't support that, although vendor Q does. Yes, but your current license doesn't do that, you'll need this license instead. The joke is once you present the "effort" required to do what they want to do, 80% of the time they'll give up on it anyways. It's the same end result. But you didn't have to say no!

Kalium 7y ago

I've worked in a shop where InfoSec tried to be the Department of Yes. They were very effective at that - they basically never said "No" to anything. The downside was that they weren't actually able to say "No" to the things that they really needed to be able to change. A lack of accountability for decisions meant that people could ignore InfoSec consequence-free. All told, I've learned that security needs to have the ability to say "No" and the organizational backing to make it stick. It's the implicit threat that makes other groups play ball. I've had at best mixed results with covering people with positivity and admiration in an effort to get them to fix things. It's often easy enough when it's something really small that looks easy and understandable. When you've got a whole architecture predicated on everything accessing everything unchecked, suggesting that maybe this absolutely amazing architecture could be even better with a tiny bit of TLS and authentication is unlikely to get you anywhere.

dogman144 7y ago
That's my fault for not clarifying, good point. Not being Dept No != Being Dept Yes. It's really not about fluffing them up with admiration (they'll see through that soon enough). It's more about figuring out what the overarching mission of the enterprise is, that in turn dev, ops, sales, hr/accounting, biz dev, and sec all have to work towards (and largely want to, under the frame of doing a good job, and assuming it's not a toxic, failing workplace), and explaining for security under that premise. This gets you a (1) way to couch sec in the 'doing a good job' language, and (2) gives you firepower with mgmt if you're told to fuck off by XYZ dev, as ultimately: business mission wins. So make your sec = business mission. Avoiding 'No' is about approaching how you sell, implement and get buy-in for lasting behavior/process change. It takes a tremendous amount of work that goes beyond a hacker news comment box, but leadership + organizational awareness are pretty key in that regard.

agumonkey 7y ago

3) makes me believe even deeper that most work life is about satisfying other people. You feel motivated because you feel capable of making X other persons happy.