4 things CISOs get wrong about AppSec

Coverage is a key component of any Application Security program.  It is typical for a modern enterprise to have 2-4 times as many applications as the security team is tracking.  This condition is caused by many issues.  Shadow IT, adoption of cloud technologies and Software as a Service platforms, legacy systems that have never been tracked, and the list goes on.  One of the first places that good pen testers (and many attackers) start is with open-source intelligence (OSINT), including deep web/dark web research.  It’s not just credentials and passwords, but systems that are targeted.  If a tester can get into a system you aren’t even tracking, there is a good chance they can gain undetected entry and pivot into more desirable targets.  This problem is real enough that Jeremiah Grossman and Robert Hansen, two of the luminaries in the AppSec space, left what they were doing and launched a startup to help companies combat this issue.

One of the trends in the industry right now is to automate all security testing.  DevOps has pushed security teams to invent new models to keep up with constant change.  These models eliminate much of the human inspection that was historically worked into waterfall and agile development sprints.  The problem is that the models aren’t just being used on the CI/CD workflows, but full automation is being applied all over the place.  What you end up with is a bunch of false negatives, because nobody is looking at the code that is being shipped out the door.  Regular manual review of application snapshots is essential to make sure a business logic flaw hasn’t exposed a vulnerability that you can’t accept.

Quantifying security risk is something that the industry continues to struggle with.  We use heat maps and high/medium/low scorecards to discuss known vulnerabilities and make decisions about which ones to fix vs which ones to write off.  The biggest problem this has created for security leaders is that this isn’t how the rest of the business deals with risk.  When talking with peers in their organization, CISO’s need a common language and criteria to measure the impact of what could happen.  Find out how the other groups look at risk, and align what you are presenting to leadership with that.  Start measuring what you are doing.  Small data first, and grow from there.  Quantitative analysts don’t say things like there is a medium likelihood of being hit by a hurricane this season.  They say things like “there is a 2% chance of sustaining a $10M property loss across our facilities in Southeast Texas between July and November of this year”.  Find someone who can help you quantify your program and it will change how you are perceived in your company.  Rich Seiersen and Doug Hubbard wrote a great book on this subject titled How to Measure Anything in Cybersecurity Risk that is worth checking out.

Unlike an attack against your network, your applications have a much higher likelihood of involving different vendors, contractors, cloud providers, and people who long ago worked at your company that aren’t listed anywhere in your IR Playbook.  You need to know who wrote the application, what kind of documentation exists, who supports the application, what kind of logs are being kept (and persist), what cloud vendors or outsourced third parties are part of the picture, and how the contracts are written so you know what kind of response you can expect.  It is important to plan and practice how you will respond if hit by an attack against one of your applications.  Traditional IR planning practices apply, but make sure you include the elements that you will need to lean on, if (and when) things go south.  Get a $0 IR Retainer in place with a firm that has experience not just in networks, but has an application security team as well.   Perform a tabletop exercise using an attack against a critical application as part of the scenario.

The opinions expressed within this article are the personal opinions of the author. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.