Nov 7, 2019 - Heather Simpson    

The security tightrope: balancing security with ease-of-use

How do you balance user experience with the friction that’s introduced when trying to keep something secure?

This blog post is Unfiltered

We sat down with GitLab security engineer Shawn Sichak to talk about the challenging act of balancing user experience (convenience!) with the friction that’s introduced when trying to keep something secure.

Shawn Sichak Headshot Name: Shawn Sichak

Title: Security Engineer, Security Operations

How long have you been at GitLab?: I joined October 2018

GitLab handle: @ssichak

Connect with Shawn: LinkedIn / Twitter

Tell us what you do here at GitLab:

As part of the Security Operations team, I’m involved in events ranging from incident response and log analysis, to the development of tooling and automation to help contribute to and improve the security of the GitLab products and GitLab.com services.

What’s the most challenging or rewarding aspect of your role?

There is a balancing act in security between user experience (convenience!) and the friction introduced while trying to keep something secure. Friction creates drag, and drag slows progress. You want to help keep people and the company as secure as possible without unnecessarily getting in their way or slowing down their work.

I find that challenge incredibly interesting. When you are able to develop automation or other methods of enabling people to do the right (secure) thing by default, it’s a very rewarding feeling.

And, what are the top 2-3 initiatives you’re currently focused on?

Similar to my colleague and fellow security engineer Jayson Salazar's response, I’ve been working on developing and implementing new ideas and tooling around helping our team gain deeper visibility into more of the domains here at GitLab.

We are moving towards a more proactive approach to security response, where automation can help us perform actions in a consistent and repeatable manner, helping the Security team scale. We are laying the groundwork now for much bigger things to come by aggregating, analyzing, and alerting on many diverse data sources so that the outputs can then be fed into further automated response pipelines.

What is the most significant piece of security advice you could provide to a colleague or friend?

It’s pretty simple and common advice (so common that Paul, Alexander and Alex cite it as their go-to security advice), but not heeded often enough: utilize unique passwords per service and set up a password manager to help generate, store, and access them as needed. Also, enabling two-factor authentication (2FA) everywhere it is available. Every additional step you take to make it more difficult for an attacker will significantly decrease the chance of your accounts being compromised.

But I’d also recommend giving Bruce Schneier’s excellent article on ‘The Security Mindset’ a read. While the goal isn’t to give everyone a cynical view of the world, I think understanding the mindset and thought process from an attacker’s perspective can be incredibly beneficial while trying to keep yourself (and others!) secure.

What is the most important emerging trend you see in security?

It is refreshing to see security become less of a walled garden and more incorporated into other areas of software and systems development. Taking development techniques and best practices from software/systems engineering and integrating them into security workflows has already been producing some exciting new tooling and ideas (SOAR, compliance-as-code, etc).

I think continued advancement in areas that better enable security teams to “scale” are going to be incredibly important. Whether that be through the use of automation or more actionable data; security teams are going to need to be creative to keep up with the pace of change/development and the ever growing amount of data to analyze.

From the perspective of your role, what’s GitLab doing better than anyone else in terms of security?

Transparency - it’s something not given much consideration when it comes to security in most organizations. Being transparent about issues and vulnerabilities (while still protecting our customers and services) allows the wider community visibility into how we handle security internally, but also enables contribution and promotes collaboration; ultimately strengthening our security.

There are obvious exceptions to the rule and not everything can be public, but I think that transparency in security is something that we as an industry should strive to do a better job at.

Is there an area of security research you think deserves more attention? Why?

I find the field of security in Industrial Control Systems fascinating. The intersection between cyber and physical systems presents its own set of unique challenges, and the stakes are so high, ranging from the integrity of public utilities to telecommunications entities.

In the past decade, how has your area of expertise changed?

Looking back - it’s been an interesting ride.

I remember coming out of school still unsure if I wanted to pursue a career in hardware or software. I eventually narrowed the job search to two offers - designing robotics for a bottling facility or a software engineering position in telecommunications. Went the software path and never really looked back.

Since then, I’ve moved from development to systems work to research, eventually settling in security which allows me the opportunity to work on a little bit of everything!

Now, for the questions you really want to have answered:

VIM or EMACS?

VIM - as they say, EMACS is a great operating system, lacking only a decent editor.

You get one superpower, what is it?

The ability to always pick the fastest checkout line at the grocery store. I currently possess the opposite power.

Is a hotdog a sandwich?

I don’t like to talk about religion.

You need pancakes. IHOP or local pancake shop?

I really appreciate how accurately the first statement of this question describes most of my life. With that being said, mom and pop shop first, but I support all pancakes.

Photo by Pixabay from Pexels.

DISCLAIMER: This blog is intended for user-generated content submitted by the GitLab team. The views and opinions represented in this blog are personal to the author of each respective blog post and do not represent the views or opinions of GitLab unless explicitly stated. All content provided on this blog is for informational purposes only. Neither GitLab nor any of the individual blog contributors ("Contributors") make any representations as to the accuracy or completeness of any information on this site. Neither GitLab nor any Contributors will be liable for any errors or omissions in this information or any losses, injuries, or damages from the display or use of this information. Comments are welcome, and in fact, encouraged. However, GitLab reserves the right to edit or delete any comments submitted to this blog without notice should GitLab determine them to i) be spam or questionable spam; ii) include profanity; iii) include language or concepts that could be deemed offensive, hate speech, credible threats, or direct attacks on an individual or group; or iv) are in any other way a violation of GitLab's Website Terms of Use. GitLab is not responsible for the content in comments. This policy is subject to change at any time.

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg