Blog Post

The Why and Symbology

  • By Brian Glas
  • 10 Jun, 2019

This is an introductory post on why you should consider working with us.

This is an intro to PG Security Advisors. PGSA is a small AppSec firm that is built to help people build up and build out their software security programs. It's more about the programs, governance, people, culture, process, tooling, integration, expectations, training, and on and on. We aren't a pen test company. It's not that we can't do it, we just focus on larger scale challenges as it's been proven time and again that one simply cannot test themselves secure.

I've always liked to build things with a purpose. All the details have a purpose, they all mean something. I've done this for as long as I can remember. I've spent weeks on a single diagram, tuning, and tweaking, each shape, color, shading, pattern with a specific meaning. I've built the elements around PGSA the same way, here are some examples of what I'm talking about.

You will notice in the name we are "Advisors" and not "Consultants". This is deliberate. For many people, the term consultants have a bad connotation. Consultants like to charge large fees, parachute in, give you a large report of what's wrong and then say "good luck" and head out. Not all consultants do this, but enough of them did to sour the term for many people. I like the term "Advisor" much better. It connotes a long term relationship built on trust. For centuries, people have relied on their trusted advisors, because they understand that they don't have the time to learn everything they need to know in all the different areas.

The logo was designed to project the understanding that our focus is more strategic. It's not about hammering out some security test in a week to check a box. It's about how to fix your process so that you aren't in the situation in the first place. Thinking four, five, ten moves ahead. Working through scenarios to try to determine a better path forward for your organization. The three pieces in the main logo are deliberate choices as well.

The King represents your critical assets. If this piece is taken, you have lost. There is always something that you need to protect, that's why security exists. Unfortunately, not everyone has your best interests at heart. It can be difference for each organization, it might be intellectual property, brand, customer trust, or something else. At the same time, PGSA strives to be pragmatic and realistic, we don't deal in FUD (Fear, Uncertainty, & Doubt) that are too often used to sell security.

The Castle (or Rook) represents your organization. An organization's culture is everything for security. Your culture will dictate what is held in high esteem by your employees. If your culture accepts that security is the security team's responsibility, most of the people outside the security team won't terribly care about security and determine that it's just not their problem. If your culture embraces security as one of many disciplines that are a shared responsibility that people are rewarded for caring about, then you will see real progress on many fronts.

The Knight is your security team and champions. These are the people that are responsible for representing your organization from a security discipline. They work together to learn how to translate the larger world of application or software security into how it should be implemented at your organization. They help spread the knowledge of what to do and how to do it for your organization. 

The colors are shades of grey, as rarely in application security are things simply black and white. One does not eliminate risk, but rather has to make decisions on how best to manage the risk to the business. All decisions have costs and benefits, making good decisions will swing that ratio in your favor.

One of the primary goals and services at PGSA is a Security Advisor Program. This is where you get someone to spend up to a set number of hours a month helping you with your security program. It might be helping build a case for funding, performing a current state analysis using OWASP SAMM, building or reviewing policies/standards/etc, or building process integrations between security and developer or business processes. Work that needs experience that is either too difficult or expensive to hire full-time positions.

If this sounds like something that can help you in the application or software security area, please reach out and we can chat.
By Brian Glas October 11, 2020
Compare SAMM and BSIMM models
By Brian Glas June 12, 2019
Something that's been bouncing around in my head is the topic of data collection and analysis, specifically in the security realm. I've been part of the OWASP Top 10 2017 data collection and analysis process (might be for future ones) and also starting to work on the OWASP SAMM Benchmarking project which will likely encounter similar challenges.

Data collection and management is a large challenge for projects in Open Source organizations like OWASP. As a group of people that come together with a common goal and wanting to be neutral for the most part, there are some areas that are many times just taken for granted at a large organization that can present some hard challenges to a loose band of people trying to help in an area they are passionate about.

For the OWASP Top 10, for many years the data collection was a fairly quiet affair. Then a few people started making noise that it should be a fully public dataset so anyone could work on it. While this is a noble goal, there are real-world trade-offs for doing that. For the Top Ten 2017, we had to explain to organizations that were considering contributing data, that "yes, anyone in the world will be able to see the raw data." There were several companies that didn't contribute due to that stipulation. I was working with an organization that over half a million records that could be contributed, but legal couldn't approve the release as they feared (and rightly so) that someone could use it against them. Not to breach anything, but to attempt to damage their brand.

So you have to ask yourself, would you rather have a larger dataset that isn't public or a smaller dataset that is? Almost all the contributors to the Top 10 2017 were service providers. The numbers they reported were already an aggregation of a number of their clients that are anonymized. Which makes sense, there is a tangible risk to disclosing your internal vulnerability metrics to the world; but if it's already an aggregate dataset, then it shouldn't be able to be traced back to individual organizations (generally).

We've had similar discussions for OWASP SAMM. We are working on a project to build a benchmark of software security maturity scores and are working through the details of how to collect, manage, and distribute the data. It's a pretty challenging task to work through the details for how to collect data, allow updates, determine what metadata could/should be collected, how anonymous it should be, how to handle versions, how to provide meaningful metrics to help organizations learn from others while protecting the submitting organizations and earning their trust, and so on.

Should the raw contributed SAMM scores be public data?

Honestly, in my opinion, the answer is no.

Also, I think the raw contributed data for the Top 10 2020 shouldn't be either.

Look at all the industry analysis produced by numerous organizations. I don't believe any of that raw data has been provided to the public, and I'm ok with that. I have my own opinions (as I'm sure you do as well) about some of those reports, but at the end of the day, we have to choose whether or not to trust their analysis. Sometimes we can, sometimes, not so much. If we can get more data, with a broader reach, and possibly a little more detail, I think it's totally worth it. You may not agree with me, and that's fine. Just stating my opinion based on my experiences.

I would love to be able to start trying to build a knowledge base of which vulnerabilities are more prevalent in specific languages and frameworks among other correlations, we have all this data in tiny silos; we really need to put it to good use. I've previously talked about so many different questions that we haven't been able to answer because of the lack of a good clean, solid, large data set. Then we could start trying to solve what we can in the languages/frameworks themselves and teach people how to code securely for the remaining things. So much could be done in this space if we sit down and make it a bit more of a priority.
More Posts
Share by: