loading...
Cover image for Five things I knew about security, before I knew anything about security

Five things I knew about security, before I knew anything about security

hayleydenb profile image Hayley Denbraver 👩‍💻🥑 ・5 min read

I am a Developer Advocate for a company (Snyk) that specializes in helping devs find and fix security vulnerabilities in their open source dependencies. It is my job to share resources and insight with dev communities and, more importantly, to listen to devs and get feedback on what they need. Prior to this I was a webdev who had read the OWASP Top Ten a few times. It has been a bit of a change to say the least.

I honestly sometimes feel like a professional confused-person. I am new to security, and a lot of my coworkers understand security in a really profound way. But it is valuable for the company to have the perspective of someone who is new to security, because a large portion of their customer base is as well. And that is okay. I am learning things each week.

I have a secret though, and I think I should share it.

You know more about security than you think you do.

Really.

Take it from someone who knows more than she did six months ago. Take it from someone who still has a lot to learn. Humans have a security mindset even if they haven't written a line of code. There are things that you do in your day to day life that give you perspective on security.

So I present to you five things I knew about security, before I knew anything about security:

Thing 1: Granular permissions are important

We all practice this in our social lives. I tell things to my husband, or my best friend, or my mom that I would not tell my coworker, or an acquaintance, or a stranger.

When I was in grad school, my flatmates and I all had permission to be in the common areas of the apartment, but my individual room had a separate lock. So did theirs.

When I am at a conference, my badge gets me into public areas, but not necessarily backstage, or to separately ticketed tutorials. An organizer's badge would get them into those spaces.

Granular permissions are part of our daily lives and have generally been set by social norms, purposefully designated relational boundaries, or some kind of physical security (like the locked apartment rooms). They may have been purposefully stated, but you also might have just assumed the defaults. You may not have been aware that you grant granular permissions in your personal life, but you absolutely do.

Think about these granular permissions in your life. Be purposeful about them for happier, healthier relationships. And be purposeful about permissions in the apps you build as well. Ask yourself whether the defaults make sense and remember that it is always easier to grant a new permission than it is to revoke one.

Thing 2: You don't have to outrun the bear

There is an old joke about two hikers that come across a bear while on the trail. They start to run away. One hiker says to the other, "Why are we running? We can't outrun a bear!" The second hiker replies, "I don't have to outrun a bear, I only need to outrun you".

There is a lot of truth to this. Bad actors will often go for low hanging fruit, crimes of opportunity, or the path of least resistance. Stay ahead of your peers to stay ahead of the bear.

Thing 3: Car alarms are useless

Have you ever investigated a car alarm? I have, on exactly one occasion. My neighbor had gone out of town and his car alarm went off--and kept running for 36 hours. That got my attention, but not quick enough if his car was actually being stolen.

People are not roused to action by car alarms because they have a ridiculously high rate of false positives. For every car alarm triggered by a true crime, there are hundreds seemingly triggered by the wind, a falling leaf, or a dog looking at it.

If you are warned about 50 security vulnerabilities (which don't end up being actual vulnerabilities), what is the likelihood that you will pay attention to the next alert?

Thing 4: Two factor authentication is safer

Before I was a latch key kid, I was an after school program kid. My mom worked prosecuting child abuse cases, and was very serious about security with my brother and me. If there was ever an occasion where mom was unable to pick us up there was an established protocol.

First she would call the program and let them know who was going to pick us up (first factor). Second, when the friend or relative arrived to pick us up, they had to tell us the "secret word"--a previously established secret phrase that I knew my mom would only tell someone that she trusted to take care of us (second factor).

When I heard that word, I would know my mom had really sent the friend or relative.

This IRL two factor authentication (2FA) added a layer of security and reduced the chances that I would leave with a stranger, or even with a non-stranger who hadn't been properly authorized.

If you use a service that offers two factor auth, take them up on it. It is still possible to compromise 2FA, but significantly harder. Remember, you are trying to outrun your peers, not the bear.

Thing 5: Getting help is good

Getting help is good. Get a locksmith. Get a home alarm. Use the tools available to you. Run with pepper spray.

In the software world this is true as well. There are a lot of groups out there who can help you with being as secure as possible. Groups like Snyk can help you with your open source dependencies (we have a free tier!), other groups build code scanners or perform pentesting, and more. Use the resources available to you. You don't have to do it alone. In fact, making use of the tools available to you is preferable, because you benefit from the learning process and development that they already went through.


I wrote this piece to help people who are new to security, or even new to any aspect of software development. It may feel like you are starting from zero, but you are not. Technology is not some mythical subject that can only be approached by the chosen or whose mastery process is distinct from any other skill. Your current knowledge and experiences are a good starting point, and you absolutely can learn and improve. Onward!


"Alarm.com" by Lauren Danford is licensed under CC BY-NC-ND 4.0

Posted on by:

hayleydenb profile

Hayley Denbraver 👩‍💻🥑

@hayleydenb

Software engineer, developer advocate, technical content creator. Believes coding can and should be fun and that teams work best when they are inclusive. I am on the market right now.

Discussion

markdown guide
 

Super job - it's all very much common sense if you can approach information security from a human perspective, I'll bung in another couple I use and a war story (non-technical!)

Layered security: you keep important documents in a locked filing cabinet, inside your locked house (possibly in a private apartment block). This makes breaking multiple locks slower and riskier for the attacker - if it's not worth their time/risk they'll pick an easier target.

Separation of responsibilities: you have the key to a private mail box, however the post office staff must open the building for you to use it. An attacker now needs to coerce two parties, not one, again increasing the time and risk involved for them.

War story: while a student, my car was stolen twice in a year and joyridden round the town. I fitted a flashing red led, it was never touched again - deterrents work to keep the bear moving along.

 
 

If you are warned about 50 security vulnerabilities (which don't end up being actual vulnerabilities), what is the likelihood that you will pay attention to the next alert?

This is the main problem I have with most dependency security checkers. Even the expensive tools like BlackDuck, JFrog XRay, Nexus IQ report way too many false positives. It's not worth the huge license fees.

I work on a big Java enterprise application. We make a lot of use of parts of big frameworks. All tools I've tried report security issues on parts of the framework we do not depend upon. Just because I use Spring Framework does not mean I use Spring MVC. They are different components which are explicitly different dependencies. It's not like the case if Commons Collectiins where a security bug exists in the package, but we simply do not use that code.

 

Yeah, that is a problem and one we are still hacking on.

There are three ways we try to address it, but there is definitely room to improve.

  1. We make it possible to 'ignore' those kinds of vulnerabilities. Basically, you can review it once and dismiss it without addressing it because it isn't relevant to you and then it doesn't obscure the information that is relevant.

  2. Snyk have a research team that curates our database. Basically they have removed some general false positives and add metadata to other vulnerabilities to help you make a conscious decision whether something needs to be fixed or isn't relevant to you.

  3. Also, we have a product that can monitor an application that is up and running, and let you know if you are calling a function, etc that is compromised. Then it is much easier to prioritize what you are going to fix. It is obviously not the solution for everyone, but I am excited to see where it goes.

 

Great write up! As someone who uses Snyk, the cli is easy to use, but please pass on the message for adding Gradle support for the Intellij IDEA plugin. 🙏

 

I think this is on our roadmap, but I will pass it along regardless. Expanding support for IDEs is definitely something we want to do!

 

Remember, you are trying to outrun your peers, not the bear.

This truly summarizes security in today's world.

The bear will always to chasing. Just don't be the last in line closest to bear.