Why Your Security Program Fails #1

You have a security group. They are passionate, trained, and competent. But security is still weak based on customer audits. Why?

Reason Number 1:

Your organization only performs security audits late in the quality cycle. Development neither engages nor listens to your security team because of a variety of reasons.

1. A culture of coddling developers so they feel elite, and therefore they know it all so they do not believe they require outside expertise.
2. Your Security team is in a quality group, and are therefore sneered at in North America.
3. Your Agile process has been broken to mean anything to anyone at any given time so therefore its missed as part of the agile cycle.
4.  Your hipster/hideous beard crowd is breaking things at the speed of Google because that's how code is made today.

Based on this any security issue may require a serious redesign. (Really?!, why can't our MongoDB cluster be exposed on the public internet?). Unless of course product managers can sweep it under some other rug.

Blame marketing. That normally works.

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.

Burp Suite, Firefox, SSL, HSTS, and sec_error_unknown_issuer

If you are using Burp Suite Pro intercepting proxy you will know you have the following chain.

|Browser| <=>|burp|<=>|Target Website|

In an SSL environment burp will send its own self signed cert to your browser while behaving as the client to the target. 

But if the target website uses HSTS (HTTP Strict Transport Security) and you use Firefox as a client then you will have problems. What you will see is a sec_error_unknown_issuer error and no ability to add an exception.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate. 

Ok, So we know the site is normal - in our case its an internal staging environment. We could use another browser but there is a way to work around this.

Originally I tried downloading the burp self-signed certificate and importing it into the Windoze certificate manager by double clicking the .crt file. However this did not result in any change, I still had the sec_error_unknown_issuer problem.

The solution here is to manually import the Burp certificate into Firefox by:

1. Firefox->Hamburger Menu at Top Right->Options->Advanced->Certificates->View Certificates
2. This will display a Certificate Manager dialog. Select Import and then select the Burp Certificate.