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:

• The reasons why standardization fosters creativity
• Other cultural obstacles you may be facing that impede standardization
• Some steps you can take to start shifting your company culture towards acceptance of standardization

Why Standardization Increases Creative Opportunities

Why does putting standards in place lead to more creativity?

To make a long story short:

1. Standardization reduces time spent on oft-repeated tasks that you already consider correct (e.g.; your up-to-date methodologies and procedures that don’t need to be reinvented).
2. By saving time on those oft-repeated tasks, there’s more time left to work creatively on the problem at hand.

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 Standardization, Pentesters Are Wasting Time

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.

Obstacles to Standardization

Let’s look at the major cultural obstacles to instituting established methodologies at InfoSec companies.

Hacker Ethos

People who are interested in hacking and pentesting often have a lot of traits in common, such as:

• A high value on creativity.
• A high value on being able to do things spontaneously and off the cuff (because that shows true understanding).
• Disdain for following rules.
• Disdain for authority.

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).

Knowledge-Hiding

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:

• The ability to learn new things and understand how things work together.
• A willingness to contribute to a team.

One way to combat this obstacle is to show the many benefits of sharing knowledge, including:

• Other people more easily recognize your expertise, which leads to respect from peers.
• Other people recognize your willingness to share and teach others, which also leads to respect.
• Others are more willing to share with you the things that they know, which increases your knowledge.

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.

Past Process Failures

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.

Start Small

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 Applies To Everything

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.

Next…

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.

Was This Article Helpful?

Security Roots’ founder Daniel Martin conceived and created the open-source collaboration tool Dradis Framework in 2007. The success of that application led to the creation of the Security Roots company and Dradis Professional Edition software.

Over the years, Security Roots has helped hundreds of InfoSec clients improve their team collaboration and report creation processes. If you have any questions about what we do or the solutions we provide, please fill out our Contact Form and we’ll be in touch right away.

Knowledge transfer refers to the process of transferring knowledge and best practices from one part of an organization to another, or from person to person. For InfoSec companies, keeping team members up to date and knowledgeable is indispensable.

And yet, knowledge transfer is often not made a true priority at InfoSec companies. In the rush of constantly tackling projects, the knowledge transfer process often falls by the wayside and is ignored.

In this article (part of a series on making your InfoSec company stand out), we’ll look at some reasons why knowledge transfer is so important. And we’ll give you action steps you can take today to help improve knowledge transfer at your company.

Why Is Knowledge Transfer Important?

Before discussing ways to improve knowledge transfer, let’s go through some of the main reasons why knowledge transfer is so important.

Information Changes Quickly

State-of-the-art status in the information security field changes daily. New technologies, applications, and upgrades come out constantly, and new vulnerabilities are continually being discovered. You have to stay on top of new technologies and information, or you run the risk of missing vulnerabilities and looking bad to clients and colleagues.

More Knowledgeable Team = More Efficiency and Profitability

If knowledge transfer doesn’t happen and your team isn’t up to date, it leads to all kinds of problems in your company’s workflow and efficiency.

Is the following scenario familiar?

An employee, John, does a security assessment on an Android app. He finishes the job, makes a few notes in a company wiki, and moves on to other jobs. A few months later, another employee, David, works on another Android app, his first one in several months. David takes a look at John’s notes, but the notes are far from complete and aren’t in an easy-to-follow format. So David just ends up doing the research on his own to get up to speed on new Android vulnerabilities and attack vectors.

This is a common occurrence at many InfoSec companies. If knowledge transfer were optimal, there would be a system in place that ensured that John communicated his learnings in a complete format to his colleagues. It’s not enough that John occasionally writes up his findings; there needs to be a system in place that ensures it is always done. And if the way John writes up his findings is not standardized and organized, it’s going to be difficult for other team members to get much use out of it. Without a process in place that makes it easy for the rest of the team to absorb the information and put it to good use in the next test, team members will likely ignore it.

Most importantly, an optimal system will ensure that the new knowledge is used. Often, there’s no mechanism in place that makes it mandatory for the knowledge transfer to take place. Your team might be doing their best to keep your methodologies and procedures up to date, but it doesn’t mean much if there is no process in place to ensure that that documentation is being used.

When your team transfers information efficiently, lots of good things happen:

• Testers can work well on many types of projects (not just the technologies they were experts on when they joined your team).
• They spend less time on routine, documented tasks and more time doing important, job-specific work.
• They spend less time digging around for information that should already be present and easily available for them.
• You can more easily prove to clients why your technicians are able to handle the jobs and technologies they’re assigned.
• Your company gets more jobs done and is more efficient overall.
• Your company performs better (which improves your reputation and helps justify your rates).

Technicians Are Happier

Also, apart from making your clients happy, efficient knowledge transfer makes your team happy. They are trained up on more technologies and, as a result, their resumés are improved. Your company also becomes a more sought-after place to work, which is great for attracting talent.

Obstacles and Struggles with Knowledge Transfer

To be fair, knowledge transfer is difficult at any company; it’s just a lot more difficult in InfoSec because there’s so much new information coming out all the time.

Also, most people in InfoSec know that knowledge transfer is important. The main challenge is in the implementation of knowledge transfer. It’s not a question of “Why would we do that?” but a question of “How do we make it happen?”

One of the main obstacles in changing any business process at an InfoSec company is workload: there are often so many projects coming so fast that it’s difficult to set aside time to brainstorm and administratively set up a process. (This is what leads to most problems in implementing process improvement.)

Sometimes there is a knowledge transfer process in place, but it is mostly ignored. As was the case in the previous example (with John and David), the “official” process may say: “Testers have to write down their findings on new vulnerabilities for this application in the content management system.” But there is nothing that actually verifies this is being done, nor is there a template for this report, so it falls by the wayside.

Or a company might put specific team members in charge of updating specific methodologies. For example, one person might be in charge of keeping the WordPress testing methodology up to date. And he does this, and does it well, and the company thinks it is doing its part in enabling knowledge transfer. But what the company doesn’t know is that nobody is actually using the information.

Some InfoSec companies try to address knowledge transfer by holding regular team meetings, in which new work and vulnerabilities are discussed. These meetings may be great for team building, and a breath of fresh air coming off of working on back-to-back projects, but often these meetings are just paying lip service to knowledge transfer. Often the meetings are informal and not everyone is present. Also, if the meetings are not yielding concrete changes to the process (which they usually won’t), they are not valuable in terms of long-term knowledge transfer. The team members present may learn a few odds and ends and connect socially, but there is no real transfer of knowledge to the entire team or to a dedicated database.

Knowledge transfer is about more than making information available. It is about putting in place processes that push the information where it needs to go.

Overview of Knowledge Transfer Process

Now let’s take a look at the steps of knowledge transfer. Again, this is pretty rudimentary and may seem like common sense. But breaking this process down into discrete steps can help you understand what your company needs to do to optimize their process.

1. Identify who has the knowledge in an organization (e.g., testers who have recently performed tests on specific technologies, or testers who are known to be experts in specific techs)
2. Giving the knowledge holders motivation to share knowledge (e.g., through negative incentives, positive incentives, or by showing them how the process itself benefits them)
3. Using a set process to facilitate the transfer (e.g., a process that must be followed step by step; or it might involve a software that ensures steps are followed)
4. Measuring and evaluating knowledge transfer (e.g., testing team members themselves, or using post-project surveys to see if knowledge transfer is happening and is effective)

Improving Knowledge Transfer

Here are a few suggestions for processes you can put in place to start improving knowledge transfer. What’s best for you will depend largely on what systems you already have in place, but we’ve tried to give some good general tips.

Create Or Improve The Process

The first step on the path to improvement is not to set up a knowledge-sharing meeting or to put people in charge of being methodology “owners.” These may seem to be tempting and easy first steps. The problem, though, is that they don’t help the process. And, as we’ve been saying often in this series, it’s all about the process.

If you don’t yet have a knowledge transfer process in place, the first step is to set one up, no matter how simple. If you already have a process, the first step is to improve it in some way, no matter how small.

For example, maybe you currently have a basic knowledge transfer process that involves testers leaving a few basic notes on your internal wiki. Some steps toward improvement might be:

1. Creating a specific format of post-project information that must be completed for every project, by every tester
2. Having a way to incorporate that information into your official written methodology for that technology
3. Requiring a sign-off in a spreadsheet that that information was recorded
4. For subsequent projects involving that same technology, requiring a sign-off by testers that shows that they reviewed the current methodology
5. Requiring a post-project survey by subsequent testers that judges the existing methodology information

These are just examples, and much will depend on what you currently have in place. But the point is that your first thoughts should focus on improving the process and making the process not only required, but verifiable and auditable.

Dedicated InfoSec software platforms can also be a part of the overall solution, as these applications are focused on process standardization.

Surveys

In our previous article, about scoping, we discussed how surveys of clients can be important. You should also have surveys and questionnaires in place for your workers.

For example, a post-project survey of the tester can ask questions for each technology, such as:

• Were there any problems with the existing methodology as written? What were they and how would you fix them?
• What resources (e.g., online documents, presentations, or internal resources) did you use in working on this project? Where can they be found?

The longer the tester waits to complete the survey, the more information will be lost. So, ideally, it will be part of the process to complete it right after the test is done. Perhaps an automated form could be emailed to the tester, scheduled on the same day as the scheduled test completion date. And the form could expire after a certain amount of time, which would notify a manager that the survey wasn’t completed in a timely manner.

And, most importantly, there must a process in place to do something with this information. It must be required to be shared and used.

Ask For Employee Input

It’s important and valuable to ask for employee input on problems. Testers are the ones closest to the problem; they are often the ones with the best ideas on how to solve problems with the process. Sometimes, though, their input is never tapped.

One specific question you can ask is: What processes have you seen in place at other companies you’ve worked for that you thought were very effective? This will often give you many suggestions and opinions on processes that have worked and not worked.

Aside from pure information, asking for input lets employees know their opinion is valuable, which is great for morale. It will get them thinking about other ways they can help improve the process.

Conclusion

Improving a business process of any kind can seem like a daunting challenge. It can feel like the problem is too large and amorphous to tackle effectively.

Alan Weiss, the business consultant, is famous for making the following point: If you improve just 1% a day, you’ll double in ability roughly every 70 days. In other words: small, incremental changes can quickly add up and become large over time. So don’t be discouraged by the apparent difficulty in tackling process change. Remember that every little thing you do to improve a process will have a large cumulative effect as time goes on. Focus on improving just 1%, but for every project your team delivers.

Next…

Hopefully we’ve given you some new ideas on ways you might improve knowledge transfer at your company. Let us know if you found the information helpful or if you have some unique things you’ve done to improve knowledge transfer at your company.

In the next few articles in this series, we’ll be discussing some other areas of project management, including ways to improve report standardization, and ways to stabilize and/or increase revenue.

Was This Article Helpful?

Security Roots’ founder Daniel Martin conceived and created the open-source collaboration tool Dradis Framework in 2007. The success of that application led to the creation of the Security Roots company and Dradis Professional Edition software.

Over the years, Security Roots has helped hundreds of InfoSec clients improve their team collaboration and report creation processes. If you have any questions about what we do or the solutions we provide, please fill out our Contact Form and we’ll be in touch right away.

If you’ve found this article helpful, please reach out and let us know how the information has worked for you. And keep an eye out for the future articles in this series.