Why We Should Remove Lazy From Our Vocabulary

Lazy is a word I see much too frequently. Sometimes it comes up as the key reason a web application is insecure or because an internal network is missing a backlog of patches. Sometimes it’s used to explain peoples attitudes towards security in general or their lack of acceptance of a particularly scathing report.

Sometimes you see it brought up in postmortems as the root cause for issues, e.g. “the service desk is lazy”, “users are lazy” that’s why there was an incident.

The Truth About Lazy

The truth about “lazy” is it doesn’t exist, and if I asked you to think of someone who is “lazy” or a time you felt “lazy”, you’ll probably list of qualities like:

  • Staying in bed all-day

  • Unwilling to work

  • Not finishing work in the time allocated

The trouble with all these examples is that they are all very one-sided and only acknowledge the “problem” rather than why things aren’t getting done. What we are doing is misrepresenting unseen barriers.

A GIF from Catching Fire, Katniss is speaking to Beetee Latier and Wiress. Wiress points out something by the corner of the table near Plutarch. Beetee comments he can see a force field, on the top left side. Katniss looks on struggling to see it however, Beetee continues to explain he can see a glass like texture.  Wiress points out it is to separate "us and them" while Katnis acknowledges it is likely her doing.

The Grind

We’ve all been there; you have x days to conduct a penetration test and get the report back to the client. In their report, you probably won’t mention the word lazy. But you might be thinking about it, and you might be telling your coworkers about it.

You might dance around the subject in the walkthrough, alluding to the sponsor that developers are lazy because they missed vital security features, and you might even think it when you get you’re 7th email asking about detailed remediation that you can’t provide.

As a consultant focusing on a tiny technical component, you can’t dissect the root cause of how this problem ended up there. But we must start to look beyond blaming anyone engineer, developer, project manager, manager, or business unit (referred to from here on out as “contributors”) and use more specific language.

Being Specific

Having worked with countless businesses and spoken at length to employees as part of various penetration testing and governance assessments, I’d argue that no contributor picks not to deal with a security problem because of an unwillingness to work or use energy. Instead, contributors make these decisions because:

  • There is no demonstratable risk, and there are more significant issues to address.

  • The business is pressuring the contributor to focus on user features instead of addressing the backlog/security issues.

  • Contributors are not provided with adequate security-focused education and can’t address security issues in a meaningful way.

  • There is an expectation for contributors to keep things up to date with minimal to no downtime – but the business won’t compensate the contributor for out of hours work.

  • The business you are working for/with/in has a poor security culture, and contributors are overwhelmed by a lack of buy-in, backlog, cultural expectations.

Of course, these are just examples, and each person will have witnessed or seen glimmers of these unseen barriers.

What can I do?

By removing the word lazy from our vocabulary, we present ourselves with better opportunities to help contributors with their security. Depending on the number of these unseen barriers, we can address issues differently, either by changing how we deliver our work, how we talk to our clients, and how we speak to each other.

By no way does this mean “lower ratings”; instead:

  • Ensure we demonstrate risk so businesses can justify spikes to fix security issues.

  • Accept that sometimes a business will get a security assessment and may not have the capacity to deal with the number of issues presented.

  • Accept that sometimes a business will get a security assessment and may not accept the risk rating - i.e. your threat model isn’t their threat model.

  • Provide free or discount resources for security contributors who want an assessment and make things better. Still, the business refuses to support the initiative (i.e. a meeting with stakeholders to discuss benefits).

Depending on how your business works, some of these recommendations might not work or might not be suitable. I challenge you to think of ways to remove laziness from your vocabulary and help empower people around you.

I leave you with this tweet from Tatiana Mac: