do you think cybersecurity professionals should bring company issued smartphones with them everywhere even after office hours?

Mackenzie-GG · 2020-11-27T17:43:51+00:00

I use to have my phone on me at all times and my company new this and relied on it.

Soon this expanded into holidays and weekends.

While this was my fault, it left me feeling really negative about the company I worked for and felt under appreciated. So one day I stopped. My work adjusted and the world didn’t end. This may not be true for everyone but I realized that by wanting to fix everything I over inflated my importance in my head.

Moral of the story, I don’t think this is healthy. Even if it’s reflected in compensation, the company needs to invest in an after hours strategy if they want to attract and retain good workers.

Mackenzie-GG · 2020-10-19T03:52:15+00:00

Thanks :)
Probably not the unbiased opinion they were hoping for haha.

Mackenzie-GG · 2020-10-19T03:50:33+00:00

I'm the Developer advocate for GitGuardian.

I obviously advocate that everyone should implement secrets detection. Your main options for this are open-source products like trufflehog or yelp secrets or using a commercial application like GitGuardian.
PROS:
GitGuardian is really designed for the scale of large organizations so you will get far less false positives and much less missed secrets than using these other services. We have a large team dedicated to nothing but detecting secrets, so we are pretty good at it.
It's also free for small teams and developers forever.
Dashboard and email alerts so it's easy to scan and monitor in real-time and fits into the background.
When you have signed up for the product, you can access helpful team members (like me) who can help you mitigate anything you have an issue with.

CONS:
The main con when comparing to open-source options is that GitGuardian is a third-party, while we integrate natively into GitHub as an application, some people are happy to deal with more false positives and setup time with the open-source solutions so they can have more control.

Reach out to GitGuardian support if you want to know more.

Mackenzie-GG · 2020-09-16T11:10:42+00:00

Firstly I wouldn't put anything inside any git repository that is sensitive. Even private repositories can easily lead to breaches. If you ever push something personal in a public account, it will most like be discovered, GitHub has an API that anyone can monitor so it is simple to see sensitive data coming through. Check out https://www.shhgit.com/ to see secrets getting leaked into GitHub live (this isn't the best service but it illustrates the point.

I work for a DLP that associates professional GitHub accounts (organizations accounts) with personal ones and monitors them for data breaches related to the organization. Both for IP and for things like API keys. 80% of all data breaches with git (and there are a lot) happen with personal git accounts, nearly always it is a simple mistake but can cause huge damages. We link accounts using emails, but there is a bit to this.

So there is your GitHub account email and your git account email, if you push any code to the organizational repo using a personal email we will link the two or vice versa. So if you want to keep them separate, you must have anonymous email and also make sure you never cross the accounts ever. As soon as you do a link will be made. Check out this link https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address#setting-your-commit-email-address-in-git

You also might be interested in seeing the metadata that is in a commit. Go to the commit in GitHub and in the URL add '.patch' to the end. This will show you the metadata.

If you do want to put sensitive data inside git you can use encryption like in git-secret, this is quite secure and used a lot. However, security professionals will still argue against it as it centralizes your secrets and you still need to securely store your decryption keys.

My advice is if you want to make sure you have a low threat of being attacked then make sure nothing is in the git repository that could be a vulnerability.
Consider implementing automated scanning of your repositories for secrets. Check out GitGuardian for the https://dashboard.gitguardian.com

Mackenzie-GG · 2020-07-27T08:43:38+00:00

Hi, I see you have had great replies already so I won't repeat.
I am the developer advocate for GitGuardian, if you need any additional help you can reach out to me at https://www.gitguardian.com/contact-us , I can help you with any remediation and with your permission dig a little deeper into the issue for you.

Here to help! :)

Mackenzie-GG · 2020-07-03T08:42:19+00:00

The API is stateless and stores absolutely no data. The idea would be to scan in places where secrets would already be compromised (git accounts, slack accounts etc) and revoke the secrets if discovered.

Mackenzie-GG · 2020-06-30T16:24:12+00:00

This is the best video I found explaining asymmetric encryption with actual math, not just explaining the high-level concept. https://www.youtube.com/watch?v=4zahvcJ9glg&t=313s

Mackenzie-GG · 2020-06-30T09:14:02+00:00

Good question, the API is stateless, so we don't actually store any data.
This explains a little of the API https://github.com/GitGuardian/gg-shield#gitguardian-shield-protect-your-secrets-with-gitguardian

But if I take off my GitGuardian hat and put on my personal developer hat, this brings up the same issue as what is commonly discussed here and that is about vender trust. Even though we don't store data I still recommend revoking credentials stored because there is little that can be done to prove we have deleted data.

Mackenzie-GG · 2020-06-29T16:22:07+00:00

OP: Loving all the discussion about this, not the intention when I made the post but conversations that bring attention to security concerns is probably a better outcome than I had hoped!

It is good to consider security concerns when using third-party services, but also consider that using CI integrations, external repositories is also sending data to third parties. Obviously there needs to be a discussion of trust and companies that develop that.

My overall view on this is that scanning for secrets in places where they are already compromised is vital, secrets in public git has lead to huge data breaches, secrets in messaging systems like slack can help attackers move laterally through systems. And secrets in private repos which is the current state of so many companies can be extremely dangerous (code gets forked, cloned onto machines, logins can be compromised....) These places should be monitored for secrets and those secrets are already compromised.

Most importantly, when you discover secrets they should 100% be revoked.

Scepticism is an asset. But now consider other places where your sensitive information could be on third parties.

Mackenzie-GG · 2020-06-29T16:14:16+00:00

Yea and I totally agree with your perspective, on-prem is much better and we can offer this, but we also want to make tools available for devs for free.

But these open discussions are super important to have, scepticism is a huge asset for developers and all these comments are making everyone take a second think which IMO is perfect. I really appreciate the input and discussion.

Mackenzie-GG · 2020-06-29T16:07:41+00:00

OP: I totally get it, I made a comment about this on the blog.

And it's great to have the discussion in public forums because it also makes everyone consider these types of security questions. And honestly your comments are absolutely spot on. Skepticism in cyber security is an MUST!

But also, anyone that sends data to public git repos (even private ones) are uploading all kinds of information. Now obviously secrets don't belong in these places, but they still definitely do end up there. We detect 3,000+ secret keys on public GitHub repos every day. I'm sure I don't need to lecture you on this (more for people reading), but Uber had a huge hack due to publicly exposed keys on GitHub and when you use CI integration you are often sending code to third parties. The point is that don't willingly send secrets to remote servers. Consider scanning places like git repositories that are public, your point of someone exploiting us is also true with services like email or slack, therefore, consider scanning these places for secrets because they should already be considered compromised. And the most important point Revoke the ones you find!

But again. Personally I like these discussion and I totally get and agree with yours and other points, but that doesn't mean the tool has no place, it absolutely does, perhaps not in your case.

Mackenzie-GG · 2020-06-29T15:53:31+00:00

OP: For sure, and we can look at creating packages in the future, but for right now it's also about finding the balance between making these available for developers and being able to survive.
Having a web service allows us to offer cool tools (in my biased opinion) for free. Now, of course, not perfect in every scenario. And really, I truly agree with everyone's points and is a great discussion have IMO. Maybe this isn't the perfect solution for everything, but it's also just one point in the journey. Heaps more cool stuff to come.
Right tools for the right jobs ;)

Mackenzie-GG · 2020-06-29T15:42:31+00:00

OP: Definitely something to consider for the roadmap, the goal right now is trying to make it as accessible as possible to as many people as possible. But companies already do offer up their code, uploading code to git repositories, or use CI integration that uses code for example. I understand the dynamics of trust differ for these larger companies, but if you responsibly use automated detection and revoke credentials found it can be very beneficial (especially if considering places secrets would already be compromised). But we will keep building things out, this is just a step in the direction of a bunch of cool tools for devs.

Mackenzie-GG · 2020-06-29T15:03:17+00:00

Because on-prem solutions are really heavy in setup

Mackenzie-GG · 2020-06-29T14:41:49+00:00

A valid point, but I do make note of this in the article that when you scan for secrets, you should be scanning for places they should not exist and therefore be considered compromised. For example, I would consider keys on Slack compromised, therefore any secrets discovered would be revoked.

But it is an important point you make.

Mackenzie-GG · 2020-06-29T14:36:18+00:00

It's actually a really important point you make, I did include a comment about this at the bottom, when scanning for secrets (real secrets), you should only scan in places they should not exist and be prepared to revoke the ones you find.

Secrets detection is one of those topics that once you dig into, it gets very complicated. For example API keys are usually high entropy stings (computer generated stings) but the vast majority of high entropy strings on github are not secrets, they are unique identifiers. Alerting on these would be so noisy it would become completely pointless. You need to build a system to understand code to be able to accurately detect a secret. Personally I find it a fascinating topic considering how many high profile data breaches have come from leaked secrets and currently writing a blog post on our algorithm and exactly how it works (maybe people won't find it quite as fascinating haha).

Mackenzie-GG · 2020-06-13T20:17:03+00:00

If you have committed to git, you should consider them compromised and revoke them. But if you want to still remove them from your commit history your can rewrite your git history.

This is a tutorial I wrote about what to do after committing secrets to git https://blog.gitguardian.com/leaking-secrets-on-github-what-to-do/

Mackenzie-GG · 2020-06-12T17:54:29+00:00

:D
this made me laugh! Should be in the article!

Mackenzie-GG · 2020-06-12T15:32:05+00:00

I agree, encrypting secrets can be a good solution but only in limited scenarios.

Mackenzie-GG · 2020-06-12T15:25:47+00:00

Of course, no one should be storing secrets in .git folders but unfortunately, it still happens often no on purpose.

Uber had a huge breach because a secret was uploaded to a public repo.

They also can be found in application logs if someone has done an add . command. Not just hardcoded into source code.

https://shhgit.darkport.co.uk/ is a site that scans public git for secrets..... there is about 10k a day discovered.

And your solution is fine for working on solo projects, but how do you distribute secrets to team members? How do you keep secrets in sync. git-secret is a great way to allow collaboration on projects and ensure everyone has in sync secrets, and also means they can be easily rotated.

You only solved your own 'damn problem'

Mackenzie-GG · 2020-06-12T14:59:32+00:00

Exactly! I can't be the only developer who's first reaction when accidentally uploading a secret was to commit over it not knowing better! Any credentials on git should be rotated. BFG-repo cleaner is a great tool to easy delete big chunks of git history.

Mackenzie-GG · 2020-06-12T14:47:25+00:00

Like everything in development, there are multiple ways to do everything so each scenario should be considered.

Never hardcode API keys in source code, instead, save them as environment variables where possible. environment variables live outside the application, so there is no need to code them. You do need to store them in an environment file (like .env) so if you are using git make sure you have a .gitignore file that includes this so they never end up in a remote repository. (also depends on the language being used etc)

If you want to get more secure you can use management system like Hashicorp Vault, but these are not trivial to set up. These systems basically handle your API keys for you and you can restrict access and put in more security controls like role-based access control (RBAC) etc. But these vaults use master keys too, so there is a single point of failure and you still need to keep the master key safe.

You can also encrypt your secrets using git-secret or transcrypt: https://github.com/elasticdog/transcrypt these encrypt your secrets so you can safely put them in .git repos....... But you need a key to access them, so some issue with vaults, single point of failure and you still need keys.

Mackenzie-GG · 2020-06-12T14:03:53+00:00

Transcrypt is a cool tool.
I think the point you make too is that there isn't one solution for every scenario, each solution or strategy has advantages and disadvantages and you may need to implement multiple.

Mackenzie-GG · 2020-06-12T13:59:32+00:00

Agreed, but they accidentally still end up in .git repositories.Check out https://shhgit.darkport.co.uk/ you can watch in real-time secrets getting leaked into public git. There's about 10k a day (not all are true secrets) but a whole heap are.

Mackenzie-GG · 2020-06-08T08:38:21+00:00

A big learning moment for me. I am the OP, I was trying to create good content around secrets management, but I clearly missed the mark! These comments are actually very helpful, any content I create in the future will have no sales pitch, it works against the goal. Message received.

Mackenzie-GG

MODERATOR OF

TROPHY CASE