What’s it like working to secure one of the most transparent organizations in the world? To be a security practitioner in a highly iterative and agile environment? What does that look like and what kind of people thrive in that environment? It takes a certain individual ... curious, analytical, collaborative and dedicated. Of course, there’s more than meets the eye when it comes to our GitLab Security team; they also tackle the hard topics like the age-old 'Is a hotdog a sandwich?' debate, Vim vs Emacs, and Linux distros.
We take securing the GitLab product and service and protecting our company very seriously. But, we try not to take ourselves too seriously. We hope you learn something new in this series, but that you enjoy yourself too.
Name: Paul Harrison
Title: Senior Security Engineer / Interim Security Manager, Security Operations
How long have you been at GitLab? I started in January 2019
GitLab handle: @pharrison
Connect with Paul: LinkedIn / Twitter
Tell us what you do here at GitLab:
I’m responsible for defining and implementing the operational security response processes and procedures to handle new and emerging risks to GitLab the company, the product, and GitLab.com. I’m also involved in day-to-day security event handling and engaging with partner teams around GitLab on any related questions or issues.
What’s the most challenging or rewarding aspect of your role?
The most challenging AND rewarding aspect is helping to design our security posture and working to meet those goals one step at a time. This is incredibly unique and challenging as we’re 100 percent remote, the topography of the company and its environments is constantly iterating, and we want to ensure we hold true to our values by being as transparent and open as possible.
And, what are the top 2-3 initiatives you’re currently focused on?
- Operational Security Architecture: Designing the end-to-end flow of how security risks, events, and incidents are handled across GitLab. (Handbook MR coming soon!)
- Log Aggregation Working Group: Analyzing, documenting, and working with Infrastructure and Development teams to improve the quality and efficiency of logs being produced by GitLab-CE/EE and GitLab.com.
How did you get into security?
Dialing into local BBSs in the early '90s, IRC in the mid-90s, and being introduced to reading material like Phrack, 2600, and other amusing bits at an early and malleable age. Combined with a general interest in discovering how things work, breaking them in the process, and the kind of interesting things you can find!
In the past decade, how has your area of expertise changed?
10 years ago I was almost entirely focused on the security and compliance tools necessary to keep a solid grasp on enterprise email (well ... as best as you can!). From there, I broadened my horizons by taking on security management and architecture of local and remotely hosted environments, then compliance for interesting and terrifying acronyms like GDPR. This has resulted in a decent breadth of knowledge in many areas … and enough to be dangerous in others.
What is the most significant piece of security advice you could provide to a colleague or friend?
Please, please, please, please use a password manager like 1Password, or LastPass, or Bitwarden (examples, not endorsements, YMMV and pick what fits your workflow best!) and start using it to generate and save unique and difficult passwords for each of your sites or services. You won’t need to remember them and so you don’t need to use a memorable one. Then, while you’re at it, turn on two-factor authentication (2FA), and not that SMS/text message-based one. Use an app like Google Authenticator or Microsoft Authenticator, which will give you the six-digit number (aka Time-Based, One-Time Password) on your mobile device, or better. Having strong, unique passwords and 2FA enabled will significantly decrease the chance of your accounts being compromised.
GitLab is very unique in that we strive to be incredibly transparent...about everything. What sort of challenges does that present to you as a security professional? What opportunities?
First, the opportunities:
Striving, and for the vast majority of situations, succeeding, at being transparent is a hugely rewarding and helpful experience for both GitLab and the community. At first I was sceptical and from working with very tight-lipped organizations with their well-massaged disclosure communications, my mindset has been to not “air our dirty laundry.” But, being able to be transparent about vulnerabilities and issues means:
- The community can see how we became aware of, handled, and resolved the situation, then subsequently learned from it so we won’t repeat the issue. This information might help them in their own environment, or their own processes, and, we hope, might also increase their trust in our product!
- We can give credit to all the awesome, hard-working, and talented people at GitLab who come up with clever and creative solutions to protect our customers and their data. When the issues are public, anyone can see who worked it, came up with the obscure and amazing solution, and deployed it. In most companies this information is part of their secret sauce, but this is something we can, should, and do celebrate.
Now, the challenges:
- The need to keep vulnerability details close so our customers have the opportunity to update before it’s being exploited in the wild.
- Old habits die hard, particularly in the Security community. When the default state in most companies is to lock away and carefully communicate a well-crafted and rehearsed statement, transparency is something to get used to and can be uncomfortable for many people who’ve been in the industry for a while.
- Determining, and sticking with, the few rare scenarios where, due to the sensitive nature, it is necessary to keep certain data confidential. Scope creep can be hard.
What are your thoughts on cybersecurity bachelor’s degrees as a way to scale training of security professionals?
With the premise of a bachelor’s degree being more focused on providing the deep, foundational knowledge and enabling people to continue to learn after completing the degree, a Security-focused bachelor’s program could be valuable. However, the continued learning aspect is absolutely a necessity in this space as, despite OWASP Top 10 (for example) having largely remained unchanged, the rest of the security landscape has shifted tremendously in the last decade. Without having the willingness to grow and the tools at your disposal to understand how to grow, you would have a difficult time.
Now, for the questions you really want to have answered:
Favorite Linux distro?
Debian, specifically Debian Stable. It just works. Fast and reliable for server use and great for a desktop/workstation. I’ve been using Debian since version 5 or 6 and it is always my first choice when setting up a new system.
You get one superpower, what is it?
I’d like to be able to look at any one plant and make it to grow at any speed and to any size I wish. I could make one beanstalk be 100 feet tall and 3 feet wide, or a fully formed spruce tree but scaled down to a foot, all in a matter of seconds!
Now, it’s time for the age-old debate: Is a hotdog a sandwich? And, on that note, is a taco a sandwich?
Neither a hotdog nor a taco are sandwiches! A sandwich is formed by bringing together two distinct pieces of something to hold an object or several objects between them, sandwiched between them one could say! A hotdog or taco are different from a sandwich because in both circumstances the hotdog itself (aka meat-tube) or the taco fillings are inserted into a crevice formed from a single continuous piece of something, which is no longer sandwiching anything but instead is actually formed to enable the holding of the hotdog or taco-fillings.
