So far in our series of articles on InfoSec business improvement, we’ve talked a lot about the benefits of setting up processes. Established processes, like having defined and regularly updated methodologies, improve the consistency and accuracy of your tests; this benefits your clients and, as a result, your company.
And we know we’re probably preaching to the choir a bit on this one. Most owners and managers would agree that having set methodologies in place is ideal. The problem comes in implementation: getting people to follow the established procedures all the time, every time.
Process improvement can be especially difficult at InfoSec companies. This is often for cultural reasons. One major obstacle is the hacker ethos, which places a high valuation on creativity and spontaneity. For many pentest professionals, the mere idea of processes and procedures can be a killjoy. Standardization is not, on the surface, fun or exciting.
But what is often not understood is that process standardization actually leads to more opportunities to be creative, not fewer. In this article, we’ll talk about:
Why does putting standards in place lead to more creativity?
To make a long story short:
Let’s imagine a craftsman who makes wooden chairs by hand. The craftsman has a process he follows. He selects the wood a certain way, he cuts the wood a certain way, he assembles the pieces using established, proven techniques. It’s only towards the end of his process that he adds the details that are most outwardly creative and that have the most in common with art: ornamental carvings and designs, maybe some painting.
The main bulk of his work, though, is a set process that he follows. The more efficient he makes his fundamental process, the more time he has to dedicate to the more creative elements.
This is a bit similar to pentesting. Pentesting is also more a craft than it is an art, but it does offer the opportunity for creative and artistic problem-solving. The bulk of the time on a pentest (maybe 75%) should be established procedures: i.e., your testers are using a given methodology for the technologies involved. The remainder of the project time (maybe 25%) can then be spent on creative approaches to breaking the system.
Without set, standardized, and organized methodologies in place, your testers are often winging it on a job. They are spending a lot of time “re-inventing the wheel.”
For example, a tester may be doing the same vulnerability test on a Citrix environment as another tester did the week before, but because there’s no set repository for your company’s knowledge and no set methodology, the tester spends time researching the most current attack vectors and techniques worth pursuing. And that’s time he could have spent creatively hacking, after performing the minimum, required tests.
So instead of spending 25% of the project time trying some unique approaches to breaking the system, he winds up running out of time, having only enough time to complete the bare minimum required tests. He may get some small satisfaction out of feeling he “did everything on his own”, but at what price? He has lost an opportunity to really focus his creative talents on the system at hand. Most importantly, the client has not been served optimally, either.
Let’s look at the major cultural obstacles to instituting established methodologies at InfoSec companies.
People who are interested in hacking and pentesting often have a lot of traits in common, such as:
Understanding that these traits may be true for some of your team members will help you communicate with them. This may also help you convince them why standardization should be something they support and not something to fight or run from. Standardization will leave them more time to have fun (i.e., break stuff and learn new things).
In our last article we talked about knowledge transfer and how important it is for your team members to share information. But tech workers can have a lot of ego and pride associated with the knowledge and experience they’ve accumulated. This can manifest as an unwillingness to share knowledge, and possibly even a desire to hide knowledge.
This is not just a problem in InfoSec. This happens in many companies, across all industries.
Hiding knowledge can also be seen as a strategy to make oneself more irreplaceable. The thinking goes: “If I tell my coworkers everything I know, what use am I? They’ll easily replace me.”
But this is a false conclusion. It is based on the idea that an employee’s worth is based on mere facts, checklists, and procedures when, in fact, an employee’s worth is based on much broader factors, including:
One way to combat this obstacle is to show the many benefits of sharing knowledge, including:
Again, these can be ingrained cultural obstacles that are hard to overcome. But the more you can make your team members see these benefits, the more you can start to make progress in shifting the culture.
Another obstacle may be that your workers have negative associations with past company attempts at standardization. This may be attempts made at your company or at companies they’ve previously worked for.
For example, one of your testers may hear that you’re trying to set up repositories for methodologies and think something like: “They tried this at my last company. They had me go through weeks of establishing methodologies and putting them in certain places. And what happened? Nobody cared and nobody ended up using them. These attempts at standardization are a waste of time.”
Unfortunately, due to the sub-par way most process improvement is implemented, this can be an understandable reaction. Understanding this resistance on the part of your team members can help you combat that resistance in terms they will understand.
For all the obstacles mentioned above, it’s important to start with small steps.
One of the first small steps is simply communicating with your team. Talk to your team members and try to educate them on the ideas in this article.
Have team meetings where you emphasize that standard protocols won’t constrict them; they’re a ticket to more creative freedom.Tell them you want to save their prime brainpower for solving the big problems, not reinventing the wheel on the usual ones, and standardization allows them to do that.
As we talked about in our last article on Knowledge Transfer, it’s important to first ensure that a process is being used by everyone. In other words, don’t spend massive amounts of hours on trying to set up a process and getting people to contribute to methodology repositories if you’re not sure or can even verify if the process is being used.
Start small. Create a simple process that your team members must follow (even if that means they are still doing a lot of other things on their own). Make sure the process is being followed by all team members and establish a simple means of verifying that it is a living, useful tool.
Once you have a system in place that is being used, then you can incrementally improve it. As we’ve been talking about in this series, this is the basis for long-term, lasting improvement in a company.
This improvement process can play out in all other aspects of your company.
For example, once you standardize your scoping and scheduling, and get them down to an exact, efficient science, that leaves more time for your team to work on more important things, like brainstorming new, creative ways to do those tasks, or working on getting new business. Or if your salespeople have a streamlined system for handling and nurturing leads, this will result in them spending more time on brainstorming better selling strategies.
In short: every system you standardize opens up more room for creativity and improvement.
Hopefully with this article we’ve given you increased clarity on some ways to combat some cultural obstacles you may be facing at your company. Specifically, we hope this article has helped you see the reasons why process standardization leads to your testers being more creative and productive, not less.
If this article strikes a chord with you, please reach out and let us know the challenges at your company and maybe some unique things you’ve done to enact change.
In the next few articles in this series, we’ll discuss some other areas of InfoSec project management, including ways to stabilize and/or increase revenue, and more strategies for creating sustainable cultural change.
Your email is kept private. We don't do the spam thing.