Services
We often talk with companies that are thinking about hiring an FTE to help them with security. This post covers some of our thoughts and experiences in this area. As with many areas of security, there is no one size fits all approach that works here, but there are some pitfalls and ways to make it work more smoothly. Here’s the TLDR; use a tool like securityprogram.io to do the program part and hire someone that does DevOps.
It is common that organizations realize they need help with security when they find themselves spending a lot of time on 3rd party questionnaires or they need to meet some sort of client requirement around security. It’s easy to justify when a CTO starts spending 10-25% of their time (or more) on security! A lost deal is an easy trigger for more security as well.
Often the first thing a company thinks is that they want to hire someone to do the security for them. This is totally natural. A challenge we have seen with this approach is that it isn’t clear whether to look for someone senior that is a leader or someone that is technical.
The leader might be able to answer the customer questions, and help with some directional decisions. But they are unlikely to also be able to roll up their sleeves and do the work to secure the organization when it comes to end points, cloud infrastructure, etc. Hiring a leader makes sense if you also plan to make a significant budget available for tools and hands on hires. It could make sense if you are in a regulated area, and you are pretty sure you found the right leader. Most great security leaders aren’t looking for a position where they are the only person though, so you have to know that this may be the exception more than the rule if you think you found it.
A hands-on person has the benefit that they can go do security work right now. Maybe you want them to help manage IT endpoints or work in a security monitoring or engineering role. You might want them to also answer questionnaires and deal with customer requests. But be careful. Often the folks that fix things are not the same folks you want talking to customers. Very often, this type of hands-on role needs to work very closely with existing IT resources and in fact the responsibilities are not always clearly segregated.
It is surprisingly common for relatively junior security folks to be strong-minded in new leadership roles. Meaning they may feel the weight of responsibility and struggle to communicate in a constructive and productive way. They get frustrated when organizations can’t just do X,Y or Z to address an issue. It turns out that communication across the organization is a key success factor for people in security roles. So is long-term planning.
Another pitfall is looking for experience with a very specific tool instead of general technical breadth and capability. Exposure to a single security tool suggests that a candidate may be knowledgeable in an area but may not understand the big picture. I can’t tell you how many times we see security tools purchased but not used effectively. This often happens when someone likes a tool or vendor and brings them in but maybe it doesn’t fit or isn’t a priority organization wide. An increasing number of your tools should be cloud based and easier than ever to integrate. You may not want a specialist…
Sometimes these growing pains are inevitable and reflect that an organization has put off security just long enough to give itself an opportunity to be viable from a business perspective. Other times these growing pains are a sign that it is too late and security is about to catch up with you.
Whether it is developing processes, evaluating vendors or architecting the moving parts in your cloud environment - all of these things are easier to do sooner than later. You won’t know when the growing pains are coming and whether you’re on the “good” size or “bad” side of them until you actually fail.
One thing we can say, is if you ease in and start now you can be making important progress that will be valuable later. Just start now in a small or “reasonably sized” way!
Whoever you bring in to help with security is going to have to deal with difficult situations. Here are some examples:
OK, in full transparency: we built a tool to help you outsource the program securityprogram.io, but we did that because we believe this so strongly. If you can get close to what you need with out of the box policies, process templates, training materials, and core tooling and task management, why would you hire the security person?
If you can get an experienced person to help when you need and appropriate support running your vendor management, risk and audit programs, why would you hire a junior or unproven resource for that?
The costs are also much lower than even a junior FTE.
When you’re ready to hire and you’ve considered the program platform, think about where the highest impact will be.
We’re opinionated; and we lean toward well rounded doers in general, not just for your first security hire.
You might consider hiring someone who can help with DevOps automation. Coding skills are important for automation. They also suggest adaptability to different tools. You want to be able to use appropriate tooling and apply it with success. If they can use Terraform to help fix things in your cloud environment, that might be a very helpful thing. They become enablers instead of gates.
A good thing to do is to write down how you think the person is going to spend their time. We also like to do fictional one year in the future annual reviews to communicate what the expectations and areas for growth are.
Whoever you hire, communication, flexibility, planning, organization, an ability to talk about risk and some technical skills should be part of your calculus.
