[Angostura]

Calling them the 'paranoids' probably seemed like a fun idea at the time, but I wonder if it set up a subconscious bias against their work. I wonder if they had been called 'The Guardians' or 'The Defenders' there would have been a different outcome.

Seems trivial, but words matter.

[dsacco]

The Yahoo Paranoids chose their own name. It was designed to be light-hearted in a way that didn't make them seem stuffy so that engineering teams would be more receptive to their work. In my experience, this is incredibly important from the outset.

Anyone who has worked in information security for a month knows that the relationship between product engineering and security engineering defaults to antagonistic. It takes a lot of work to make it friendly and productive, and as a security professional I think "Paranoids" is much better for overall collaboration than something like "Defenders", which in my opinion reeks of self-importance.

The more pertinent issue here is management not fostering the culture enough.

[Twirrim]

Where I'm working now, we've got security engineers assigned to seating in each development team.

They're not managed by, or working for, our teams. They have their own manager and security work that they're getting on with.

Having them sitting amongst the team, however, is resulting in a much different narrative than any I've been around before. There's a much higher quality, and less antagonistic kind of engagement going on. They've become someone you chat with at the watercooler, or at their desks, instead of having to file tickets, or wait for scheduled reviews to raise things.

People can quickly consult with them and deal with a whole heap of small potential risks way early on in the development process, and it's paying serious dividends down the road.

[bananarepdev]

That approach Works well with Q&A too.

[andersonmvd]

You're talking about Squads basically. Bring different people in the same group. And yeah, QA is very similar to Security in some points, but if you think straight QA should include security. Weird to say that a software has quality without security included, but the truth is that security is specific that the regular QA usually can't handle.

[rexpop]

You've capitalized Squad, but it's hard to Google. Where did you get that term, and where is it defined outside your head?

[bananarepdev]

As xxr said, Squad is how Spotify names their (previously Scrum) teams. Other interesting concepts they use are "Tribes" and "Guilds". Take a look at the Spotify engineering practices, they are really inspiring.

[xxr]

Not the commenter you're replying to, but at least at my organization we borrow the term from Spotify.

[wolf550e]

Security engineers are seen as experts you consult about something you don't know. QA are not seen this way. Some QA engineers actually are experts that can give good advice on structuring an application in a more testable way, but that's not the norm.

[tracker1]

Most QA guys only check that something meets the spec/story requirements, not that the code is sane or testable... many don't even go beyond UI testing. That said, I think GP was referring to having a QA embedded as part of a team.

[tracker1]

You know... I keep thinking that with source control systems like Bitbucket enterprise, etc... why aren't more mid-large sized orgs requiring a security signoff for every pull-request with a pull request to master/release branches being the trigger point.

I do a lot of PR reviews, and while I may not catch everything, I will catch a few things here and there... someone with that mindset would be in a better position to handle that from the start...

Having a few security guys that do PR reviews for about half their workload would go a long way to improving things.

We're going through an audit for an internal application now... there's 1 major flaw (SSL2/3 is enabled), a minor (session cookie isn't https only) and a couple trivial (really non-issue) concerning output caching on api resources and allowing requests with changed referrers (this can be spoofed).

In any case, having auditing earlier on and as a potential blocker would make each minor change easier to deal with than potentially much larger changes... the app in question was developed for the first 8 months without even a Pull Request check in place... by then many issues regarding code quality are already too late to fix completely. :-(

[munin]

Nobody wants this.

No "security guy" who has a choice wants to spend half their workload waiting for PRs to come in so they can chime in with feedback about default configurations.

No product programmer wants to deal with some "security guy" parroting the results of an automated tool to them over a code review platform.

No product manager wants to see progress stall because the product programmer and "security guy" are arguing over whether or not a call to strncpy should be replaced with a call to strcpy_s.

In the immortal words of my generation, ain't nobody got time for that.

[tracker1]

Honestly, someone should have time for that, it's part of the problem... I go out of my way to comment on as many PRs as I can, because I'll catch things that will become problems later far more than other peers who just click approve.

The same can be said for security guys... they spend their day needing to work as well, and seeing a bunch of smaller things fly by is just as valid as a big audit periodically. It's easier to catch a lot of things before they become big as well...

There are plenty of times I'll comment (Okay, letting this through, but in the future revise to do it this way), sometimes I'll push back, but not always, that's what the review process is for. I'm just suggesting multiple approvers for PR, where one is someone who is security minded.

It's funny how many issues I'll see from other systems where someone does something per the spec, that has a flaw because they were completely compliant. Someone crafts an exploit, and I'm interested because I'd usually be more pragmatic in implementation. Last year there was a huff about JWT allowing cert overrides in some frameworks, as they don't ensure the origin cert matches a whitelist... when I'd implemented JWT, I only checked against our whitelist and ignored the property.

Sometimes security guys will see things and think of things in a way others won't... for me, one thing I often catch that others don't are potential points for DDOS target viability. Some of that comes from using node, where you do NOT want to constrain your main event loop thread. Others don't think about putting limits on JSON size, or compute heavy tasks, etc.

And, frankly, I'm tired of fixing related bugs to patterns that were broken from the start.... turtles all the way down, but the turtles are eating all the errors.

[IncRnd]

In the immortal words of every other generation :), "someone is going to find your issues. It's either you or your customers."

You don't seen to have an appreciation for the difference between a secure and an insecure product. Yahoo didn't either.

[munin]

Personally, I have an appreciation for it. I'm a working security professional.

However, for a decade and a half I've been part of many different security regimes at many different organizations. None of them had an appreciation for the difference between a secure and insecure product, and additionally, none of them were punished by the market for it. Products have success or failure because of other factors. Security is something that organizations invest in, in the best case, because it's something they believe in, and in the worst case, for compliance reasons.

So now Yahoo has a big problem because they had this breach. First of all, is this actually a big problem? Yahoo has many other big problems. Is this going to make or break the company? No. Has any security issue made or broken a company? Microsoft thought they could be broken by security, so they invested billions into it. They were wrong. They were broken because they had crappy products that people were forced to buy. They figured this out and shut down their security organization. What about Target? What badness has befallen them? Surely not to their earnings or stock prices. What about any company that has suffered a breach? The biggest thing that happens is the CSO gets fired. Maybe some vendors get fired. That's it.

This is where the questions end when you start to push for more security involvement in the product. Ultimately you will (personally!) stand in front of the CEO who will ask you "will I lose my job, or suffer some other negative outcome on that scale, if I don't listen to you?" and you will answer, truthfully, "no." And that is the end of the conversation.

[biesnecker]

Much more valuable to have the security folks a critical part of reviewing the _frameworks_, and then pushing adoption of those frameworks. Human reviewers won't catch everything no matter what, but you can make entire classes of problems go away by making them impossible to commit.

[tracker1]

Does that mean we can kill angular 1.x because it encourages points of disconnect, undiscoverable code, too much pfm (pure fucking magic) and failure?

[rz2k]

I understand what you are saying, but having been around similar dynamics in the past I think such deprecation is a little like starting off the relationship apologizing for what they're supposed to be doing.

[dhimes]

Indeed, regulatory and security are the two parts of the company that are supposed to be antagonistic in order to keep the company out of trouble. How that plays out in practice has a lot to do with the personalities involved.

[martin-adams]

I used to slip in words like 'awesome', 'clever' and 'amazing' when talking to colleagues from other teams about the work that I was doing in the hope that it would influence their perception of the work. I've no idea if it worked though.

[bduerst]

That was my first thought when I read it. A better name would have been "Tron", "Patronus", or "Endor".

Calling it "Paranoids" or "Inquisition" is just giving it another reason for people to loathe it.

[mhurron]

Infosec isn't the ones doing the defending or guarding or any of that. They're typically working with the teams to do build and maintain to ensure their policies and procedures lead to and maintain a secure posture.

[sidcool]

As a developer who is not very much into security, I am guilty of this crime. Infosec teams are very important and deserve respect and attention.