Comment by dogman144 | Hacker News Reader

Comment by dogman144 | Hacker News Reader

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.

>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!

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.

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!

>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

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.

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.

Reply on news.ycombinator.com