Edition 1: "Welcome note" and "getting started with software inventory"

Each week, this newsletter will have 1-2 essays on a topic of interest from application security.

Aug 01, 2021

Welcome note

Welcome to the first edition of Boring AppSec! In my day job, I help run Product Security for a Fintech rocketship in Bangalore. As part of it, I often research various topics related to application security. This newsletter (more a thought letter) will cover 1 or 2 such topics each week. The goal is to take a step away from bright shiny objects (e.g.: new 0 -day in system X) and talk about (almost) timeless topics in the field of application security (AppSec). While a lot of content will draw on personal experience and research, the goal is to provide some useful, actionable info and not be the authoritative word on the subject.

Keeping this going every week will be a challenge and all feedback (including brickbats) will help. Write to me on twitter, LinkedIn or email.

Getting started with software inventory

I spent nearly half of my decade long Consulting career helping customers build parts of their AppSec program. Almost always, my first question to a new client was: “how many applications does your company have?”. The answer always fascinated me. While some respondents focused on the nitty gritties of the question (what do you mean by “application”), in most cases, there was no single answer accepted by all stakeholders. My favorite was a bank where the answers ranged from “less than 100” to “many thousands” depending on who you asked.

This question is important for obvious reasons. It’s hard to secure something when you don’t know the size (or nature) of that beast. How do you secure your application portfolio, when you don’t know what’s in the portfolio? If that’s the case, then why do most organizations not have an inventory that works? Here are a few key reasons:

Given the prevalence of software in every department of a modern workplace, there is no single team which has visibility into all the software used in the company. IT should, but in most cases, their focus is not on *all* software (for e.g.: In a company building software products, corporate IT will not worry too much about where the company’s software is deployed).
Change is the only constant. I know that’s a cliche but the breakneck speed of software proliferation & ease of adoption of cloud based software means your inventory changes many times each day for most companies. Keeping them up to date manually has oversized costs. So, most inventories start out with great intentions, but get outdated quickly
Perfect is the enemy of the good: No software inventory is perfect. It is easy to poke holes (‘does not cover *all* software’, ‘collects too much data’, ‘collects too little data’ and so on) in a good inventory which works for most use cases, but does not work for all. However, waiting to build the perfect inventory before using it to make security decisions can mean not having a functioning system.

So, how do we avoid the above pitfalls and get started? Here are a list of (incomplete) ideas that I have seen work:

Start small: Successful inventories are built in an agile manner. Pilot with one business unit (or product group) and expand to others over time. Picking the right pilot candidate is key. Find the group which is representative of the company (rule of thumb: Pick a group which makes money for the organization as opposed to groups which are cost centers) and which has a history of caring about security (in relative terms). Added bonus if you have a good rapport with the folks that run that group. Once you have a success story, learn from it and replicate to the rest of the organization.
Pick the tech inline with your company culture : There is no single right tech solution. You can build a kick-ass inventory with a spreadsheet or with fancy management consulting built-analyst approved bloatware. My recommendation is pick the solution that is most inline with your organizations culture. This means, if you are a new-age startup, where everything is cloud native and all your development pipelines are automated , pick a tool like Cartography and attempt to build an automated inventory. If you are a large enterprise where business analysts and project managers drive most projects, a well-designed spreadsheet can work. If you are all in on a mega-vendor stack (think IBM, HP etc.), you should consider using a solution built by them and figure out best practices.
Have a plan for keeping the inventory current: The popular adage fails here. Well begun is NOT NEARLY half done. While you should start small, you have to plan on how to update the inventory. While the plan can be refined, this is not something you can figure ‘on the go’. Again, building a plan inline with your company culture is key
Appreciate that this is a cross-functional project: While software inventories are useful for AppSec teams, they are also useful for IT, Compliance, DevOps/Infra and many other teams. There is value in using them as your partners in help building such an inventory.

That’s it for today! There is a lot more to be researched and said about scoping, building and maintaining software inventories, but that’s for another edition (in other words, when I figure out the answers :) ). If you have a tip that has worked, drop me a line on twitter, LinkedIn or email. If you find this newsletter useful, do share it with a friend, colleague or on your social media feed.