Has Your Company made this Traditional Mistake Managing a Security Team

So my background is development. I have been on both Red Team (attacking, pentesting, Threat/risk analysis) and Blue Team (design and implementation of security features, crypto etc). Yet for some reason the Red Team is typically in a quality group.

I can understand why to a point. But in a North American (NA) context where quality is a low priority (based on my experience) this approach is a failure.

Here is why I believe this:

1. In a NA context, there are little expectation of a quality group and are often ignored. They have no seat at the table.
2. Most security issues can be resolved and avoided during architecture. Unfortunately NA development does not engage (and in one of my experiences even purposely avoids a quality based security group) at this time so architectural mistakes are made and technical debt is incurred.
3. Threat models are inconsistent. Because of a low respect given to quality groups in a North American context development groups do not respect any group in a quality organization Therefore, they will not engage and ignore competent penetration testers in group within a quality group.

Fundamentally there is a lack of respect from development management and development members towards quality group members. I know, I have been in both. The different in a NA context is that management has low expectation for quality groups and often put under performing members  there. Development then as a whole has lower expectations and less respect for these organizations.

If you then have a group of well trained hackers in a quality group whose expertise crosses between these two divides then there is a problem. Your development organization will not respect or even listen to them and your product security as a whole suffers.

The bandaid solution is to move the red team group to the development management sphere but this avoids the elephant in the room, mainly the problem with how quality groups are managed and the expectations afforded them.

Throughout my career I have extended respect to all colleagues regardless of their position in the organizational structure. Development, Quality, and support.

However based on the unprofessional behavior of Developers towards colleagues in Quality I now have less respect for development teams. 

It is development who have the problem. And they are the ones that must fix it.

The Attitude Failure of an R&D Shop

So sometimes you overhear things. Sometimes you don't have to try to overhear things. And even sometimes these things are presented to you on a silver platter with a marching band.

This is one of those times as shared by a friend who works somewhere.

So an R&D group is managed from out of town. So there are regular visitors from out of town to see what is happening in that outpost of R&D. These visitors attend meetings and (fanfare) ask questions.

When one of those visitors leave the room a local senior/lead developer states (or rather it falls out of their mouth) for the benefit of the remainder of the local people in the room:

I don't like these visitors showing up, attending meetings, and asking questions when they don't know what's going on.

So there are few points I would like to address regarding this kinds of statement:

1. You do not own the product that you are working on. They do. Get use to questions from them. Or leave.
2. These people sign your paycheque. Get use to answering questions from them. Or leave.
3. You work for R&D. It's not the other way around. Get use to it. Or leave.
4. Perhaps, since they lead R&D,they need to  ask questions so they know what is going on. Get use to it. Or leave.
5. The reason they are asking questions is because you are not communicating with them. So perhaps you need to communicate so they do know "what is going on"? Suck it up buttercup.
6. Perhaps you are so confused and scattered that you yourself do not know what is going on.

Fundamentally this shows an R&D team with a very poor attitude. The question is not who I would fire first but when I would stop.

Killing Motivation #2 - Training

Nothing tells your employees that you care like investing in them. This is normally in the form of training. Training your employees, sending them to courses, and paying for their courses, tells them that you care about their development, their career, and their place in the organization.

But what if you don't care? What if you think that your employees are merely vessels to drain and then dispose of?

In this case, not paying for training is clearly insufficient. What you need to add is a mind game.

To do this you first of all have to tell your employees at large that you support training and that you will pay for it and that includes trips to far flung exotic places like New Jersey. Then, while the poor suckers look for a course that would be appropriate them to be a better skilled employee in the company you send out an email indicating that there are "internal" and "no cost" mechanisms (like reading a book) that would fulfil the training offer. Even better, suggest they spend an hour googling some subject. If they attempt to request a course then deny it, claiming their is no budget.

Nothing says "We don't give a shit" like a good mind game.

Killing Motivation

Do you have a well motivated and competent staff? Are they coming up with new and innovative ideas regularly? Is your quality and productivity high?

Then clearly, you do not have enough rules, procedures, and lawyers.

Step 1 Conformance
Enforce conformance. Doesn't matter if its a government standard, or even your own governments standard, make conformance to ALL of them mandatory even if it makes no  sense.

Can't find a protocol or procedure of your own? Make one up.

To help the process, make believe a standard does things it doesn't. Claim FIPS 140 will protect you.

Ensure that your staff spends every waking hour at work investigating, changing, and working on conformance. This mind numbing pointless work will ensure you are well on your way to killing your deadline and demotivating your staff.

Hire more lawyers to keep that hamster running in that wheel.

Stay tuned for the next instalment...

Software Development Arrogance

During my past 25 years in software development I have met many interesting personalities. From the intelligent stars to the dysfunctional fascist. But one type of personality seems to be more common than most. I am going to talk about that today.

But first, why today? Why after all this time do I now feel compelled to scribble about this one personality?

The reason is because this industry is in crisis and that personality is a key player in the drama.

That personality is the so-called "know-it-all".

Crisis? What Crisis? Are not software and high tech companies making money? Perhaps, but that only hides the real problem. The crisis I am referring to is the security horror the mainstream media has now latched onto. Yes. I know. Security has always been a problem and the media has now only found out it exists.

The causes of the issue is complex and has many actors. From the half-baked products rushed to market to "realize-revenue", the hapless neophyte who does not consider the malicious use case, to finally, my favourite as you can imagine, the know-it-all.

And I see it all the time. No, they will not consult with experienced staff on the subject, they will roll their own. No, they will not present their design to experienced security staff, they know better. And no, they will not ask questions, since they have no questions to ask, because they know it all.  And no, they will not consider customer opinions and just deem this is what their security policy should be even though they have no security experience whatsoever (I mean, how hard could it be). They would perform their own brain surgery if they weren't unconscious at the time.

They are the bulldozers who attempt to talk over and interrupt others with their amazingness. The male of the species will announce to their colleagues that they are "brest-feeding experts"  (true story, you can't make this shit up) after they read a book because their wife (poor soul) is expecting to pop out their spawn.

This creature will look at existing code, and even though there is no reason to, change that code (and introduce risk) because it was not the way they would write it, and therefore it must be wrong.

To be perfectly honest I am not surprised we are seeing the hacking headlines. Its a long time overdue. And it will be with us for a long time until software development teams can deal with, educate, and manage this personality. And they need to do so soon, because its killing us.

http://www.dilbert.com/2013-02-24/