Number 10: Tags – Security Guardrails Series
Other than Harrison Ford playing Han Solo and tagging a stormtrooper, what do we mean by “tags” or “tagging”?
Tags or Tagging is a type of policy where developers, security or site reliability engineers (SREs) can define how the collective must tag their assets before they are allowed to be deployed in production.
Here are three steps that we see are effective for teams today:
- Gather a general consensus on the tagging structure and types from all dependent teams (development, SREs, application security engineers, etc.). This can take a while but is the most important step.
- Set up an internal policy that ensures assets in cloud platforms like Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and code repositories (GitHub, Bitbucket, etc.) have specific tags or even types of tags before they are allowed to be deployed in production.
- Why? Because, this allows security, development and SRE teams to define:
- Ownership
- Filter resources
- Identify context like if it is a production asset or not
- Define if the asset processes confidential data or not
- In/out of scope for compliance
- Specify security group IDs
- etc.
- Why? Because, this allows security, development and SRE teams to define:
For example, in k8s, you would have the ability to use admission controllers to determine whether a workload meets the tagging policy before being allowed for deployment. Similarly, in the CD world, continuous deployment systems like Spinnaker can allow for enforcement of policies like tagging requirements before deploying workloads.
3. Adopt some common tags that your industry buddies are using:
-
- Name of the application or product or project that the code repository or cloud asset belongs to
- Name of the team that owns the asset
- Environment (staging, dev, prod etc)
- Release tag info
- NOT latest (using latest tag is a bad practice)
- On cloud assets, specify the code repositories’ name where the code resides
- Internet exposed: true/false
- Processing PCI/PHI/PII: true/false
- Cost center
- Tier (frontend, backend, database, etc)
Super cool, right?! Seems reasonable, but knowing all of the assets that do not currently have tags can be a major task. If you need help, we could provide you with that unified visibility and workflow automation piece to help make this all actually possible. If that sounds like it is interesting just hit that “Request Demo” button on the top right of the page, DM us on Twitter, or on LinkedIn and we will set up time to chat about it – maybe let us know you read this post. It would make our team super happy!
Stay tuned for our next one up, Number 9: Ownership!
Past blogs in the Security Guardrails Series:
Intro blog – What the heck are Security Guardrails and why are they important?
Upcoming blogs in the Security Guardrails Series:
- #9: Ownership
- #8: Approved Dependencies
- #7: Approved Container Images
- #6: Vulnerabilities
- #5: Scanning Tools
- #4: OSS Licenses
- #3: Auto Update Dependencies
- #2: Code Reviewers
- #1: Branch Protection
Security Guardrails noun
se·cu·ri·ty guard·rail | \ si-ˈkyu̇r-ə-tē ˈgärd-ˌrāl \
Recent articles
On a recent episode of the Future of Application Security podcast, Chad Girouard, AVP Application Security at LPL Financial, talked about some of the challenges to overcome...
Read moreOn a recent episode of the Future of Application Security podcast, Dave Ferguson, Director of Technical Product Management, Software Supply Chain Security at ReversingLabs, explained why the...
Read moreReady to Scale Your Application Security Program?
Sign up for a personalized one-on-one walkthrough.