How to maintain security with an understaffed security team

Practical Security: Simple Practices for Defending Your Systems was written for "developers, admins, team leads, architects, technology generalists and all other who stand guard against the things that go bump in the network." In particular, author Roman Zabicki wrote, the book is for practitioners who work in organizations without a dedicated security staff or who have little interaction with the dedicated security staff.

"For most of my 20-year career -- mostly as a developer -- I didn't get to work with the security team," Zabicki said in an interview with TechTarget Editorial.

Having no security staff is still a relatively common phenomenon. Startups rarely have security team members -- they're often hired once a company reaches a couple hundred people. Resource-constrained companies also often lack security staff. In this scenario, others in the organization wear multiple hats -- one being the security hat.

Even when companies have in-house security staff, it can be difficult to get a moment of their time -- even in large organizations.

"Even when I worked with a large company with a couple thousand employees, only at the end of my tenure did I interact with the security team," Zabicki said.

What's a company to do? Security can't be ignored. Here, Zabicki offers some key advice.

Editor's note: This Q&A has been edited for length and clarity.

Click to learn more about
Practical Security by
Roman Zabicki.

In your experience, who do security responsibilities fall to when there is no dedicated staff?

Roman Zabicki: I'm not a consultant, so I don't have insight into what other organizations are doing. But, in my career working for a software vendor, development teams were often left to their own devices. If they thought a practice was more secure and it didn't add much time to development timelines, security could be added in. But it was very much an opt-in thing. If you happen to be thinking about it [and] if you happen to think you could do it quickly, nobody was going to stop you. But, from my experience, nobody was saying, 'Have you considered phishing resistance?' or 'Have you considered patching?'

Did you see a lot of colleagues taking that extra security step?

Zabicki: Not generally. Most of the time it was: 'We have this new functionality we have to deliver in a certain time frame,' or 'We have to improve performance to triple our throughput.' Or we'd have to upgrade to the latest version of some framework or library or product that we were dependent on. Engineering bandwidth was pretty well consumed by those kinds of concerns.

In those instances where your team had to take on security tasks, was security approached differently than a traditional security team would?

Zabicki: Security is often looked at as the thing to do after we get the main work done. That said, something that has helped get security prioritized is finding other people in the organization to repeat the idea that we need to fix security. One group that can be a helpful ally is sales folks -- especially as you get into selling to like larger enterprise customers that have a lot more scrutiny and a lot more questions about, say, seeing your SOC 2 [System and Organization Controls 2] and other policies. Or they may ask if you've remediated the big vulnerability they saw on the news. If you can work with the salespeople who are highly motivated to make those enterprise customers happy, then you can make security a moneymaker.

Why do companies with a dedicated security staff still have security responsibilities fall to other teams?

Zabicki: It has always been hard to hire enough security head count. Organizations that can't hire as many people as they'd like -- either because they can't get enough people in or they don't have the budget for it -- they have to make tough decisions about which projects to focus on. And maybe a developer is open to learning security and going through reviews or evaluations or pen tests. You have to take advantage of that.

What's your number one piece of advice to a stand-in security team member?

Zabicki: I started the book with the chapter on patching for a couple reasons. If you are wearing lots of hats -- developer, sys admin, doing backups, being a first responder to a breach -- you're not in the novel, research space, and you're not doing security research or finding new vulnerabilities. Rather, you're in the practitioner space. The job is often going to be upgrading to the patched version of some software or system deployed somewhere. It sounds simple, but it's surprisingly difficult, especially as you get to a larger organization.

Why is it difficult?

Zabicki: Take Log4Shell, for example. The simple answer (patching) to a scary issue (remote code execution) wasn't so simple. You may know what systems you have and how to upgrade them, but if you had some out-of-date software that had its own dependency on Log4j, you might not have been in a position to upgrade. And maybe vendors weren't even supporting the software anymore. Sometimes, the solution was to restart a system with extra command-line arguments that removed Log4j functionality -- but even that wasn't always easy. Some servers are easy to restart in production -- they're running clustered nodes, and you can bring nodes down and bring new nodes into the cluster with zero downtime. But some programs aren't clustered or aren't that easy to just restart.

It also became an issue of not only knowing what software you were using and what dependencies it had, but also knowing all of your servers, what's running on them and what version.

So, your first tip to anyone wearing the security hat: Take patching seriously?

Zabicki: Honing the craft of patching -- the administration and maintenance of software -- has this additional security benefit that's really big. And it's almost always going to be your response to a security issue as a practitioner. Plus, it's a never-ending task. There will always be more upgrades to the software you're running. Most of the time, the upgrades work, but sometimes, they don't. Staying on top of this is hard, but you need to. If you get too far behind, upgrades can be difficult to pull off and could require major changes -- including downtime and a lot of testing. Going back to Log4j -- if you're several years behind patching various pieces of software, that upgrade can be really difficult. There could be a lot of downtime; things could break; data could be lost -- all kinds of problems. If you're keeping software current, on the other hand, those upgrades might still be painful, but they'll be less painful. It's paradoxical: If it hurts, do it more often.

So, that's why I started with patching. If I lose people's attention after the first chapter, hopefully, I can at least get the upgrading and understanding your inventory advice across because it's what practitioners will be doing most.