How to Improve the Security of Your Applications: A Starting Point
When we implement security programs, we often advise clients to build an inventory of their applications. There are a lot of things we can do when we know what our inventory is. We can do this right in the available tools developers are already using. This post covers one way to do this.
APP INVENTORY
When we know what applications we have, we can effectively plan what work needs to be done for each one.
If we have 10 apps with secrets hard coded in the repos, we can track that until all 10 are remediated.
If we have 1,000 apps that need to have dependencies updated, we can start to put a plan in place that allows us to do that over time.
Most of the time, most companies we know, don’t do a great job of tracking information about applications, automating the collection of and making that data accessible or visible.
USE WHAT YOU ALREADY HAVE
Most projects we see these days are using some git variant—BitBucket, GitLab, GitHub, ProjectLocker, etc. Since developers are already using these platforms to store code, what if we just put the meta information in the repo with the code?
So the imagine if we add a new file in every repo: /appmeta.json.
Now we can write a program to list all of the repos for an org and pull out their security state. Well, as you will see the security state also includes more general information, which is why we called it appmeta instead of security.json. But of course, you could adapt this practice and do all of this yourself with just the properties you care about in the scope you want.
APPLICATION META INFORMATION
What meta information do we care about?
At a high level:
- Overview
- Support
- Ops
- Continuity
- Security
Security is just part of it.
Consider the following example, which we will go through section by section:
{
  "name": "securityprogram.io",
  "description": "A platform for implementing security programs.",
  "stage": "live",
  "team": "SPIO",
  "dev":{
    "slack": "securityprogramio",
    "github": "github.com/jemurai/spio",
    "plan": "https://dev.azure.com/Jemurai/SecurityProgram.io/_backlogs",
    "adr": "docs/adr/"
  },
  "support": {
    "slack": "securityprogramchat",
    "email": "support@securityprogram.io",
    "github": "github.com/jemurai/spio",
    "documentation": "https://github.com/Jemurai/spio"
  },
  "ops": {
    "email": "support@securityprogram.io",
    "github": "github.com/jemurai/spio",
    "documentation": "https://github.com/Jemurai/spio"
  },
  "continuity": {
    "tier": 2,
    "comment": "Important for SPIO business but not business critical 
   for clients.",
    "email": "support@securityprogram.io",
    "plan": "link"
  },
  "security": {
    "tier": 1,
    "summary": "Contains security information about clients. 
     Very sensitive.",
    "email": "support@securityprogram.io",
    "github": "github.com/jemurai/spio",
    "threatmodel": "",
    "soxdata": false,
    "pcidata": false,
    "hippadata": false,
    "piidata": true,
    "codereview": "2/24/2020",
    "training": "4/14/2020",
    "linting": "3/01/2020",
    "securityrequirements": "2/24/2020",
    "securityunittests": "",
    "dependencies": "3/05/2020",
    "staticanalysis": "",
    "dynamicanalysis": "",
    "pentest": "planned",
    "signal": "",
    "audit": ""
  }
}
TOP LEVEL
At the top level we have:
 
Attribute 
Explanation 
 
Name 
The name of the project 
 
Description 
A description 
 
Stage 
What lifecycle stage is the system in? 
 
Team 
Team responsible for the project. 
DEVELOPMENT
Then we have a section about the development of the app. This includes:
 
Attribute 
Explanation 
 
Slack 
The Development Slack Channel 
 
GitHub 
The URL of the project in GitHub 
 
Plan 
The location of the development plan 
 
ADR 
Architecture decision records 
The idea is to make it easy for this information to be collected and distributed beyond the development team, who undoubtedly already has access to these things and hopefully knows about them.
SUPPORT
For support, we have similar but different attributes:
 
Attribute 
Explanation 
 
Slack 
The slack channel for support 
 
Email 
How to reach the support team via email 
 
Github 
URL for issues or other project info 
 
Documentation 
Where to get support documentation 
If you are using intercom or zendesk or other support tools, you can include those URL’s here so that it is easy for everyone to find support.
OPS
In some cases, we may have an ops team that works in a different set of tools. We can capture them here for a given project. In the example in this post, it is basically the same as Dev and Support.
BCP
BCP stands for business continuity planning. Having information about the plan, contacts, recovery, tier, etc. makes it easy to standardize and find the right people when needed.
 
Attribute 
Explanation 
 
Tier 
The tier of app. Typically 1 is most critical. (Numeric) 
 
Comment 
Text around the tier. 
 
Email 
Email to use to contact BCP related team. 
 
Plan 
Link to the response plan. 
SECURITY
The security properties reflect the security state of the application.
 
Attribute 
Explanation 
 
Tier 
Numeric tier of app. (Programmable) 
 
Summary 
Text around the tier and app 
 
Email 
Who to email about security for the app. 
 
Github 
Where code lives 
 
ThreatModel 
Link to the threat model (eg. ThreatDragon) 
 
soxdata 
Does the app have Sarbanes Oxley related data? (Y/N) 
 
pcidata 
Does the app have credit card data (Y/N) 
 
phidata 
Does the app have personal health data (Y/N) 
 
piidata 
Does the app have personally identifiable information (PII) (Y/N) 
 
codereview 
When was the last code review? (Date) 
 
training 
When was the team last trained on security (OWASP TOP 10) (Date) 
 
linting 
When was linting last run? (Date) 
 
securityrequirements 
Security requirements are incorporated up to what date? (Date) 
 
securityunittests 
Security unit tests are running up to what date? (Date) 
 
dependencies 
Automated dependency checking was run what date? (Date) 
 
staticanalysis 
When was static analysis last run? (Date) 
 
dynamicanalysis 
When was dynamic analysis last run? (Date) 
 
pentest 
When was the last pentest? (Date) 
 
signal 
Signal function up to date as of? (Date) 
 
audit 
Audit function up to date as of? (Date) 
As you can see there is a lot here. You could remove attributes you don’t care to track. You could add new ones that you want to track.
NEXT STEPS
We are considering building some automation (think a tool written in Golang or JS) that you could point at a GitHub Organization and it would iterate through the repositories, pull this file and compile data - maybe even a semi static web view that would look like a rich inventory… if you’re interested, let us know. Maybe we can give you early access to help test.
