Category Archives: Security Practice

Posts in this category are about general topics on running a security team (either internal or external)

Creating Sustainable Cultural Change

In previous articles in this series on differentiating your InfoSec consulting company, we’ve talked about the importance of two core areas:

  • Process improvement and
  • Improving the customer experience

Most everyone would agree these are worthwhile aims. We all want our processes to get better and more efficient, and we all want clients to be satisfied with our work. Truly improving in these areas requires a culture aligned with these values.

But the nature of many InfoSec companies can make it difficult to change the culture. For one thing, there is often a rather frantic focus on just getting projects finished, and this doesn’t leave time to discuss bigger picture philosophies or allow time to get everyone onboard for a larger process change.

Also, the high value of technical talent often means that managers are hesitant to tackle process changes. They don’t want to take the risk of aggravating talent; they want to keep them happy. Keeping talent happy is a great goal, of course–it only becomes a negative when it interferes with other, important areas of improvement.

In this article, we’ll go over some strategies for enacting sustainable process change at your InfoSec company whilst keeping your team members happy. This article will assume you have either already read the other articles in our series or that you have some specific cultural changes you want to implement but are having some problems.

Explain How Changes Impact The Customer

Any meaningful improvement to a product or service will stem from a focus on the client experience. And most team members do want their clients to have a good experience.

But you must explain to your team members why your proposed changes are important to your clients. For example. it’s not enough to simply command: “Starting today, you must create testing methodologies after every project and share them with the team.” Your team must fully understand the full chain of events that make a new procedure important, which would go something like this:

  1. Improving methodologies means less time spent on easily repeatable tasks.
  2. Less time spent on easily repeatable tasks means more time spent on unique project challenges.
  3. More time spent on unique challenges means better service for the client.

And they should understand the downside to continuing to do things the old way.

For example, when all team members use their own methodologies and there is no consistency from project to project, this hurts the client’s experience (especially for repeat clients).

Major takeaway: Talk to your team about the greater philosophical reasons for your changes. Make them see that you are doing this for the customer.

Explain How Changes Impact The Team

In a similar way, team members need to see how changes help them do their job more easily and help them hone their craft. The logic here is basically:

  1. Making procedures more efficient means team members spend less project time on easily repeatable tasks.
  2. This leaves team members more project time for doing the fun and creative hacking–the stuff they love to do.
  3. More time spent on interesting and challenging hacking makes a hacker smarter and better at his job, which improves his standing in the industry, increases his reputation, payrate, etc.

To create real cultural change, it’s necessary to get true buy-in from everyone. And this means that your team needs to see what’s in it for them. The more you can make them see what’s in it for them, the more buy-in you get and the easier it is to shift the culture.

If you haven’t already, check out one of our past articles on how more process standardization can, perhaps counterintuitively to some people, actually increase creativity.

Get Management and Influential People Onboard

If a large company change does not have the buy-in of senior and influential members of your team, it probably won’t succeed. For example, if you have a senior tester or manager denigrate a new process openly, that has a huge impact on whether the people working with him will be more or less likely to use it.

To mitigate this conflict, try to help these team members understand the importance of the changes you’ve put in place, both for your clients and for them personally. Also explain that their buy-in is especially important in creating a trickle-down effect in the company.

An important point: You may have employees who are not technically in powerful positions but who nonetheless may be very socially influential. It’s important to discover who those team members are so you can do your best to persuade them, too.

A potential stumbling block. One possible obstacle is that some of your more senior team members may have had negative past experiences with failed process overhauls. They may be thinking, “Yeah, I’ve seen people try to do this kind of thing before. It’s pointless and won’t work.” This is actually a great opportunity to ask those members about those past attempts at change. What worked and why did it work? What didn’t work and why not? If you give them a chance to be a part of the discussion, they will feel more involved and positive about the effort.

Use Real Stories

When you try to sell the changes to your team, use real stories and anecdotes. Real stories are powerful and convincing and help people see the value of the new way of doing things. This is why companies use testimonials from customers to show the value of their products. Thought of in another way, what you are doing can be thought of as selling ideas to your team, so be willing to use any promotional tactics at your disposal.

For example, at a team meeting, you can talk about how a new procedure resulted in measurable positive results for a specific client, and read a testimonial from the satisfied client. Go on to explain how that got you thinking about extrapolating similar results across the board, and how that translated into the changes that you are going to be implementing over the next few weeks. They key message to convey is that new ideas are not coming out of thin air; they are grounded in solid value added to your clients, the company or the team. You just need to find the right way to let team members know how you got to the conclusions you did, and what needs to happen next.

Or you can get a team member to describe how a new procedure saved them time on a project and how they had more time to devote to tests that were actually intellectually engaging.

Consider Remote Workers

These days, most InfoSec companies rely on remote workers. If you have remote workers, don’t forget about them. Process changes need to be done company-wide or it’s unlikely they’ll be successful.

Plan ways to communicate the new processes to your remote workers. When was the last time you had a one-to-one with each of your remote workers? How can you expect for them to be invested and onboard new processes if you haven’t checked in with them for several months? Schedule video conferences and make sure your team knows that these are important events. If anyone can’t attend them (e.g. they need to be off-site for a client visit), go out of your way to bring them in the loop. You need to reach out to anyone and take the time to explain the importance of what you are doing, if you want them to embrace your ideas.

If at all possible, consider having all your workers travel to a single location to roll out and talk about the new changes.

Set Goals That Are Measurable (and Failable)

When the goals of a change initiative are too vague, the initiative will rarely succeed. You need to have goals that are measurable, so that you know if the cultural changes are sticking. You need to have goals that can fail, so that you know when you are not succeeding.

For example, if one of your goals is something ambiguous like: “Improve internal understanding of tech methodologies,” there is no real way to measure that. You will never know if you’ve actually succeeded.

So make your goals concrete and measurable, like “Review 1–2 methodologies each month.”

Go For Small Wins (and Small Failures)

It can be daunting to create large cultural and procedural changes at a company, we know. Especially because the people responsible for those changes can sometimes be blamed for things that go wrong.

So it’s worth pointing out that some of the best and most long-lasting process improvements start small and grow from there. You should focus on making small but lasting and widely-used improvements. You don’t have to roll out a hugely complex series of changes all at once. Instead, you can make small changes that create noticeable benefits, then track and measure them. This will create a snowball effect that leads to bigger and more widespread changes.

For some of our best ideas on making this happen in your company, read “Getting Quick Wins”.

Next…

Hopefully this article has shown you a few ideas for creating long-lasting, sustainable cultural change at your InfoSec consulting company. If you liked this article, check back on our site for future related articles.

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.

Stabilizing (and Increasing) Revenue

Many information security companies these days are struggling to maintain revenue. Many are finding it difficult to maintain their rates and their client list. The InfoSec market has been increasingly commoditized, with many standalone pentesting tools and many new competitors.

With these new market pressures, InfoSec consultancies are trying to provide as much value to their clients as possible, and are looking for ways to provide new and ongoing services.

In this article, we’ll look at some ideas for stabilizing and increasing revenue at your InfoSec company. Some of these ideas are currently being used by some InfoSec companies, but at Security Roots, we believe these ideas are deserving of wider implementation and experimentation.

You can think of this article as a brainstorming tool. As you read these insights, apply them to your company and your specific clients.

Pre-Booking Work

The first idea we’ll look at is the pre-booking of work, which is the point when you sell your services to a client for a specific time in the future. For example, a client has an app scheduled for release six months away, so you pre-sell them 60 man-hours that they can use any time during that month.

Often, this is used in conjunction with a discount on the usual rate. Maybe you offer your services at 80% of your normal rate when booked six months ahead or during a typically quiet block of time on your calendar.

This is a technique used in a lot of industries to exert some control on the ebb and flow of demand. For example, the airline industry lowers its rates during slow seasons in order to maintain smoothness in its bookings. Offering a pre-booking discount could also be a way for your consultancy to maintain some smoothness in your schedule and even out the times of the year you know are historically slow or unpredictable.

Another way to implement this would be to have clients pay for x number of man-hours, which they could use at any time, as needed. Tweak this approach even further by charging higher rates to ensure immediate access and a rapid response from your team.

Retainer Service Agreements

With retainers, clients pay in advance for work to be specified later.

Some types of retainer-type agreements include:

  • Paying for emergency response work in the event something goes wrong. This retainer usage is kind of like insurance.For a fee, you’re ensuring that someone is available for an immediate response.
  • Clients pay upfront for a certain amount of pentesting and vulnerability-seeking per month (this is basically what we talked about above, with pre-booking of hours).
  • Clients pay upfront for guaranteed access to your team consulting and discussion.

With regards to this last idea, there are many ways you might provide clients access to your team’s expertise. Your team has deep insights into vulnerabilities and testing, of course, but they probably also have a lot of thoughts on secure development practices. So, for example, let’s say a software company client is adding an LDAP authentication layer to their software. This client might find it valuable to get input from one of your team members on the process to help them minimize risks of a future compromise.

Subscription Services

With subscription services, you are trying to achieve more passive income and move away from time-intensive tasks to more automatic ones. The main difference that separates subscription-based services from retainer-type services is that your subscription offerings are not tied to the specifics of a single project. Your subscription offerings are ways to bundle your expertise and knowledge into more packageable, automatic chunks. (Subscriptions can overlap with retainer agreements a bit, depending on the services offered.)

The traditional subscription service in the industry has been the Vulnerability Assessment service, which is often mandated by different policies and regulatory bodies (e.g. monthly PCI scans). But that is not the only service you can offer.

Examples of subscription services:

Automated (or semi-automated) newsletters/emails. With a content management system, you can create a database of which clients have specific technologies, and then automatically send security-related news about those individual techs every month (or more frequently) to your clients (e.g., security releases by vendors, new vulnerability classes, latest research / white papers / conference presentations / etc.). Basically, it’s kind of an automated, personalized newsletter. You can also add in items related to specific industries (for example, sending banking-related security news to your bank clients).

Product-specific recurring vulnerability scanning. (This could also be thought of as a retainer-based deal.) The idea is that you’re running automatic scans of specific products and technologies without much need for human oversight of the tests. We’ve seen this service with WordPress site scanning, but it also works for any other widely available product category: CMS, e-commerce shop, blogging platform, enterprise portal, etc.

Threat intelligence. No matter what your opinion is on the merits of “threat intelligence”, the truth is that vendors providing these types of service have found a profitable recurring subscription model.

Compliance and legal issues. In the same way, you could automatically gather news/updates on legal and compliance issues that affect clients in certain industries, certain regions, or certain technologies, and send that as an automatic email. This ongoing communication lets your clients know that you’re watching trends and watching out for them on multiple levels as you’re saving their mental bandwidth.

Recurring Testing Services

You could charge a retainer/subscription-type service for recurring vulnerability testing of various kinds. Examples of recurring tests are:

  • Recurring scans of critical assets
  • Perimeter monitoring
  • Social engineering and phishing attempts of company’s employees
  • Random DDoS fire drills

For all testing and scanning you do, you should be tracking your activities and the related improvements in the client’s system. This will let you easily prove the worth of the work your team is doing. Keep in mind that it’s not the raw data that is important to your clients; your main value is in providing them actionable information, which will come in the form of trends, delta reporting, and comparisons with other companies.

Recurring Training and Education

You could also provide recurring training and education for your clients. This could take many forms, depending on your area of expertise or the client’s needs. Ideas include:

Employee Awareness Campaigns

These could be occasional in-person or online training sessions, dedicated to improving the client workforce’s understanding of security threats. The more specific to a client’s needs and workplace you can make this, obviously the more value the client gets. But even a fully-automatic online training could improve things for many clients.

Awareness and training doesn’t have to be limited to lessons, video, or audio. It can also mean monitoring the news and forwarding to your clients specific instances where lack of awareness resulted in a breach or some other negative outcome. The idea is to make your client’s employees have an “aha” moment and think, “Well, I didn’t know about that vulnerability, and we could be the next headline.” This targeted information can prove to them the value of your regular input on security issues.

Training on Specific Products/Tech

You could do customized or automated online training on specific products and their vulnerabilities (e.g., WordPress, Sharepoint, etc.). This goes hand in hand with your product-specific scanning service. The knowledge you gain through the scanning service can be repackaged and offered as training material, hardening guides, etc.

Monthly Calls

Similar to the retainer-style agreement, you could have clients pay upfront for a certain number of hours to talk to your staff about practical issues they are facing or potential threats they want to discuss.

Better Opportunity Tracking

We might be saving the strongest idea for last here. One of the major ways InfoSec companies drop the ball is that they don’t optimally track the many ways they might continue to provide value for their existing clients. Here are some ideas on how to improve discovery of new opportunities:

  • Follow-up. Do you check back with existing clients regularly to see what they are doing and what they may need? It should be a part of your standard protocol to check in with clients.
  • Post-project surveys. When projects are done, a survey should be given to your clients. Not only does this help discover their opinions and thoughts on the completed project, it helps illuminate the value you just provided them, which might otherwise be a bit unclear. (For example, ask, “What potential future issues might have arisen if our team had not uncovered this vulnerability?”) The survey can also bring to light other areas in which you might offer them value.
  • Tracking products and technology used. By keeping files on what products and tech your clients are using, this will allow you to proactively look for opportunities to win work from them. For example, if there is a major vulnerability discovered in Android, it can be part of your process to send an email about this to your Android app clients.

Start Small and Improve

As we’ve talked about in past articles, you shouldn’t be afraid to start small. Some people put off making changes to their product/service offerings because they think there has to be some huge, overarching plan in place before they make changes. But if there are obvious quick and easy wins you can get by making the change, go ahead and do it.

For example, you could start offering retainer-type services tomorrow if you wanted. You could toss up some copy about these services immediately and that might have an immediate impact on attracting a new client.

The thing to remember about making these changes: you will be continuously improving them. As your clients give you feedback and as your team understands the product better, you will get better at doing it. You’ll figure out how to optimize the process, how to reach more clients, and how to make more money.

So, in short, don’t be afraid to start small and improve from there.

Next…

Hopefully this article has helped you brainstorm some ideas on how to stabilize and increase revenue at your InfoSec consultancy.

If this article strikes a chord with you, please reach out and let us know the financial challenges at your company and maybe some unique changes you’ve instituted to improve your situation.

In our next article in this series, we’ll be discussing ways to enact long-term and meaningful cultural change at your InfoSec company.

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.

Standardization Makes Your InfoSec Company Smarter and More Responsive

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.

Making The Most of Your Team’s Knowledge and Experience

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.

Avoiding Common Scoping Mistakes

(Note: This article is part of a series about differentiating your InfoSec company from competitors and improving your perceived value.)

In our last article in this series, we talked about some ideas for setting in place Continual Improvement of processes at your InfoSec company. One process that is often far from perfect at InfoSec companies (and IT companies in general) is scoping.

It’s important to understand that bad scoping, when it reoccurs consistently, is a process problem. It’s not a problem with your account managers, or your testers, and it’s not a problem on the client side. It is fixable. As with most problems in business management, improving this area comes down to having a consistent process.

The Downsides of Bad Scoping

Obviously it’s hard to argue with the need for good scoping procedures. But to drive this need home, let’s look at some of the many negatives resulting from underestimating the amount of work a job will take:

  • Wasted manhours and lost profit
  • Rushed projects, which leads to oversights, which leads to client dissatisfaction
  • Conflicts with other scheduled projects for projects that go over schedule
  • Morale problems due to rushed or mismanaged projects

Overestimating the scope is less immediately harmful to your company but is still obviously bad. Overestimating scope can lead to inflated prices, which can lead to clients noticing those inflated prices and going elsewhere. It can also lead to your testers noticing that you are charging inflated pricing, which may hurt their impression of the company’s ethics.

Many InfoSec companies operate in a constant whirl of activity, working multiple projects back-to-back and simultaneously. You would think this would create an impetus for optimizing scoping procedures, but unfortunately, often the opposite is true: the company is so inundated with work that they have never had time to study their processes and implement new ones.

Scoping Problems

Now let’s look at a few specific ways scoping problems often arise on InfoSec projects.

Clients May Not Know What They Need

Often, the client representative taxed with communicating their needs to your company is not knowledgeable about the problem. There are a few ways this can happen…

Often a non-technical manager or employee is told: “We need a security check; get it done.” Or the owner of a small business or startup knows he needs security testing, but doesn’t know any more than that. They may have no awareness of the technologies involved in their application or website, or of the different pentesting options available.

This situation leads to obvious problems in communicating the scope of a project. There must be a process in place to gain very specific info about the project, or else there will be blind spots that won’t become apparent until the project is started, by which time it’s too late.

Even technically proficient people may be ignorant of what’s involved in pentesting. Even many skilled developers are not familiar with how much work, and what kind of work, goes into a pentest.

This ignorance is not necessarily a shortcoming on their part; developers and hackers just have very different ways of looking at the world. A developer is prone to see their application as a functioning whole, made up of trusted tools and libraries they’ve assembled to get the job at hand done. They often don’t think of their application as consisting of many small, interlocking parts, whereas the hacker sees an application as an assembly of cobbled-together parts and thinks about how to find the weaknesses in the joints of those parts.

This differing mindset means that even the app’s developers are often not able to clearly communicate all the technologies and systems that will need to be probed by a pentest. And this leads to similar problems in scoping.

Team Members Not Knowledgeable or Properly Motivated

Sometimes the internal staff members doing the scoping aren’t technically knowledgeable, either. Sometimes it may be a non-technical account manager or salesperson who is the first contact with clients and who also does the scoping.

Having non-technical staff as the frontline with clients isn’t necessarily a problem. It only becomes a problem when there aren’t systems in place to acquire the necessary project information (which we’ll talk more about in a moment).

Another problem may be that the employee doing the scoping isn’t properly motivated to make sure the information is acquired. Perhaps after the completed scope specifications leaves their hands, they don’t have to think about it again and no one brings up problems to them later. This can make them a bit impervious to pressures to improve their process.

Project Information Not Updated

Sometimes it happens that a client has a project that won’t be completed for some time, but they need to pay for a security assessment now. (One explanation may be that they need to spend end-of-year budget money.)

This situation can obviously lead to problems, as the client tries to describe the technologies that will probably be in place, without knowing for sure what the application will look like months down the line. This isn’t necessarily a problem, either. The problem comes in when the scope and project specs are not revisited as more information becomes available.

For example, if there is no process in place for someone to update the project specs with info as it becomes available, it may happen that the start date arrives and the team members assigned will have no up-to-date information about the project. This can include login information and server credentials and the like. So maybe there were three days assigned for the pentest, but the team has to spend a day acquiring the necessary access information, so now the project ends up taking four days. Or, if it can’t be extended, the team doesn’t have enough time to cover all the steps in their testing methodology.

Scheduling and Talent Allocation Problems

Scheduling and talent allocation are separate issues, but some of the problems from these areas bleed over into scoping a bit. Here are a couple of ways these come into play:

  • If a company doesn’t have a good system of scoping and conducting reviews of projects, scheduling will often be off, which can amplify workflow problems. For example, if scoping is consistently off, and scheduling is much too tight, there will be conflicts between projects and missed deadlines.
  • If the person in charge of scoping doesn’t have a good understanding of the skills of team members available, the projects won’t be accurately scoped and costs won’t be accurate. For example, an account manager estimates three days for a pentest, but doesn’t know the exact skills of his techies or doesn’t factor in research/getting-up-to-speed time, so the actual time needed ends up being significantly longer.

Scoping Improvements

Now that we’ve looked at some of the major problems, what are the solutions? A lot will of course depend on your own business setup and what you already have in place. (Some of you will already be doing some of these things.) But here are some ideas for ways to improve the accuracy of your scoping process:

Pre-Scoping Questionnaire

One way to ensure that the relevant info is gathered is to make a detailed pre-scoping questionnaire a required part of every process. This questionnaire would be ideally filled out by the client company before scoping is started.

This questionnaire would include detailed questions about the architecture (existing or planned), such as:

  • Give a description of your application/website’s architecture.
  • What libraries and tools does your application use? (Perhaps an export of the environmental dependencies?)
  • Where and how is the application hosted?
  • How far along is the application and in what shape will it be by the time work is done on it?

Advise your client contact to give the survey to the most relevant, knowledgeable person in their organization.

Pre-Engagement Questionnaire

A pre-engagement questionnaire is what we call a survey that you give the client a little bit before the official project start date has arrived. As we talked about, often there is a problem with keeping the project file up to date with the state of the client’s app or the required specs (such as login credentials).

Making such a questionnaire a part of your process will ensure that your team members have what they need when the start date arrives. This step also minimizes many of the negative effects of sub-par scoping; your team members will spot scoping problems before that threaten to derail the project.

A pre-engagement questionnaire might include questions like the following:

  • Where is the application hosted?
  • What accounts can be used by the test team?
  • What are permissible testing hours (e.g. can a scanner be left running overnight)?
  • What is the final range of IP addresses in scope?
  • Who is the main point of contact for technical issues?
  • Who is the escalation/business point of contact?
  • Who needs to receive start- and end-of-day email notifications about testing activities?

Scoping Reviews

It’s important to do “post-mortems” on your projects, including the scoping of projects. After every project is complete (or possibly less frequently if that is too difficult), get together with the project principals and ask questions like:

  • Was the scope accurate?
  • Did we have time to do what we needed to do?
  • If the scope was inaccurate, why was it inaccurate?
  • What can we do in future to prevent that happening again?
  • Are the problems with this scope similar to other problems we’ve had in the past? Why is that?
  • Just as importantly: if the scope was very accurate, why was that?

When you conduct a project analysis, it’s important to be honest with each other and not to assign blame. It should be understand that the goal is improving the process, and that mistakes lie with the process, not with the team members.

Assigning New Responsibilities

Making sure project information gets where it needs to go (before scoping and after) may mean that you need to add new responsibilities to your team members’ roles. Whoever is in charge of talking to clients and scoping projects should be clear on their responsibilities and the information-acquisition process (which may include making sure questionnaires are completed, for one).

If your staff is currently kept completely busy as it is, and it doesn’t seem possible to add more to their workload, you might consider adding a new position. It could even be a part-time position. But if no one is currently keeping their eye on such details, you’ll continue to have problems with information not being present when it’s needed.

Tracking The Process

As we’ve talked about in previous articles in this series, long-term improvements come down to making changes to the process. If you aren’t making the changes a trackable and necessary part of the process, they will easily be left by the wayside and lost.

One way to make the ideas in this article part of your process is to use a workflow software (like Trello) to ensure that your team members actually go through the steps on every project. In Trello (and other similar applications), a project is moved from one step to another, which ensures that steps won’t be missed. You would put dedicated places in the workflow for “Pending Pre-Scoping Questionnaire” and “Pending Pre-Engagement Survey”. The process would not continue unless someone actively showed that those steps were complete.

Next…

Hopefully we’ve given you some new ideas on ways you might optimize your scoping process and make it more efficient. Let us know if you found the information helpful or if you have some unique things you’ve done to improve your scoping accuracy.

In the next few articles in this series, we’ll be discussing some other areas of project management, including internal knowledge transmission and ways to improve project and report standardization.

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

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.

Making Your InfoSec Team Stand Out Through Continual Improvement

(Note: This article is part of a series about differentiating your InfoSec company from competitors and improving your perceived value.)

In our last article, we talked about some ways to get some “quick wins” at your InfoSec company through practical steps you could immediately begin to affect some process improvement. But, as you know, making long-term change at an InfoSec company (or any company) requires dedication and patience.

Continual Improvement is a philosophy aimed at continually evaluating and improving a business process by using customer feedback on the product or service. By continually improving the interactions that make clients happy and by continually eliminating those things that aren’t important (waste), a company continually approaches perfection.

In this article, we’ll look at a couple of major ways to implement continual improvement in your InfoSec company, such as:

  • Using the deliverable (the report) as a driver for process improvement
  • Giving your team proper motivation and incentive to change

Deliverable Quality As Driver For Process Improvement

Most InfoSec companies are already entirely focused (often overly so) on the deliverable. At these companies, the report is the only thing that matters, and once it’s delivered, the conversation with the client is pretty much over. So making changes to what’s required to be in the report can be a great way to drive other process changes.

Ideally, as we’ve talked about in past articles (and often on our blog), a report will be much more than just a simple collection of vulnerabilities. To be the best it can be, and to set your company apart from the competition, a report should:

Give practical, actionable information on results. In other words, how significant or dangerous are the findings?

Contain an easy-to-understand executive summary. As your most important audience is often non-technical employees, the more you can communicate the situation to them, the more valuable your reports will be.

Showcase your methodology and processes. If you have great processes in place, you want to showcase them in the report. A report composed primarily of findings misses an opportunity to communicate how those results were created and why they can be trusted.

Showcase technical talent and allocation. Your company should have a way to ensure that the best people work on the problem, and this should be showcased in the report.

By creating requirements that contain these elements (effectively and accurately!) in every single report, you are also, simultaneously, creating process change. When reports are only required to contain the findings, it’s easy for your team members (managers and techies) to overlook the process, and the process is vital.

Some examples of what you can require to be in the report and how that can create broader, cultural change:

  • The report must contain information about how team members were chosen. This forces you to put in place an effective process of selecting talent for projects.
  • The report must prove the technical expertise of the team members who worked on the project. This will encourage you to create and reinforce methods of spreading knowledge efficiently throughout your organization. A more knowledgeable staff means that you have more people available to handle specific technologies, which makes scheduling jobs easier and improves the client experience.
  • The report must contain information about your process and its consistency. This forces you to initiate processes that demonstrate said consistency (e.g., team collaboration tools, up-to-date and shared testing methodologies, standard issue descriptions and ratings).
  • The report automatically is set up to contain all of the checks possible on a specific technology. This serves as a reminder to your team that those checks must be done, every time.
  • The report is automatically set up to contain a section for soliciting client feedback. That feedback will always be collected and be used to improve your process.

These requirements for the report act as powerful feedback loops that help continually improve your process. These requirements help managers easily check that the desired steps were followed on every project. And once your team gets used to the new requirements, they will automatically start to think of ways to improve the process, if only to make life easier on themselves. Which brings us to…

Motivating and Incentivizing Your Team

True company change will seldom happen without cultural change. In other words, a business will seldom really change its ways unless there is buy-in from its employees. Employees must have proper motivations and incentives for acting in the desired way.

It’s not enough to tell your team, “The boss wants it this way and that’s just how it is.” And it’s also not effective management to say, “Do this or you’ll be punished.” Behavioral change must come from within team members and should be positively motivated, not negatively motivated.

Creating cultural change may be one of the biggest obstacle at InfoSec companies. Here are cultural challenges we face in this industry:

  • Technical ability is highly valued, and there is often a tendency to “bow down” to highly-skilled workers and let them operate how they want to operate.
  • Technical workers like to think about real, technical things, and there can be a lack of awareness (and sometimes outright disdain) for “softer” issues like customer experience and customer support.

So how might you tackle this problem? What are some ways you might communicate to your team why the changes you are implementing are valuable? Here are some ideas:

Show your team that the request for process change is coming from the client, not from management. The demand for change starts with the client. All changes you make should be derived from understanding what will improve your clients’ experiences. Ideally you will have already gone through some steps to get clear about what makes your clients happy (these were discussed in our last article). It’s easier to sell the need for change to your workers when you show them exactly how your clients are asking for change. It’s harder to sell the need for change when it’s phrased as something “we just have to do now”, without explanation. So share the relevant feedback and emails from clients that are driving the change.

Explain the importance of client happiness to the company’s health, their jobs, and their lives. Client happiness is not a wishy-washy, abstract concept. Client happiness can be the difference between your company’s success or failure. Success means more money to go around and more industry respect for your team members. The more you can make your team see how the process changes have real benefits to them, the easier the changes are to implement. One way to do this is to track and analyze some key performance indicators as changes are made over time (e.g., number of repeat contracts, client survey average scores, time spent on projects) so that your team can see the concrete ways your changes are helping.

A more efficient process makes their work lives easier. Your technical team wants to work on technical tasks; they don’t want to spend time working on boring administrative tasks or editing the wording of a report. One aspect of continual improvement is enhancing your process and making it more efficient. (One example: automated report creation software reduces the need to constantly write new descriptions for the same vulnerability classes every time.) When team members see that the process changes lead to less time spent on things they don’t want to do, and more time spent on the things they want to do, change is easier to sell.

Sharing technical knowledge efficiently helps everyone. Part of improving your processes is increasing your knowledge transmission; i.e., how technical knowledge is shared throughout your organization. (We will be talking more about knowledge transmission in a later article.) Effective knowledge transmission, of course, means better client service, but it also means that your team members learn a lot more than they otherwise would. Learning new tech skills makes workers more valuable and gives them more earning potential. (It then follows that a more educated workforce makes it easier to book and schedule jobs.)

Good performance is rewarded. When team members perform at or above your expectations, have systems in place to reward them. It can be a financial reward, or it can be non-financial (e.g., granting them access to new tech training or time off). One caveat is to not hurt morale by making the workers who weren’t rewarded feel punished.

Remember, The Process Is Usually The Problem

As you move forward with a continual improvement process, you should remember that the majority of company problems stem from processes, not employees. There can be a reflex tendency to blame individuals when procedures are not being followed and goals not being met.

But, by and large, these problems come down to not having good processes. Most employees want to do a good job and be rewarded for doing a good job. The problem for managers is mainly one of defining what constitutes a good job and making it easy for workers to jump through those hoops.

Another major aspect of Continual Improvement is to encourage your team members to report problems with the process, and to make it easy for them to do so. Your tech team contains the people most knowledgeable about how the current process impacts their ability to get things done. They are the best people to get input from about your processes. Ask them questions, give them surveys, and make it easy for them to give criticism (even anonymously).

Once you get feedback on a process and you see the feedback is valid, you should act on it quickly. This avoids procrastination and shows your team that you are serious about improvement and encourages them to come forward with their ideas.

Two great resources on process improvement that we recommend are The E-Myth Revisited and Work The System.

Next…

Hopefully this article has given you some ideas on how to start down the continual-improvement road. In the next few articles, we’ll be discussing some specifics of project management, including:

  • Improving scoping and scheduling
  • Knowledge transmission
  • Project standardization

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

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.

Differentiating Your InfoSec Company: Getting Some “Quick Wins”

(Note: This article is part of a series about differentiating your InfoSec company from competitors and improving your perceived value.)

In our first article, we talked about some of the problems facing InfoSec companies: overseas competition, competition from smaller firms and consultancies, and the commoditization of pentesting in general.

The primary challenge for many InfoSec companies is to stand out–to showcase to current and future clients what makes their service different, valuable, and worth the rates being charged.

The process of re-positioning and differentiating an InfoSec company from competitors will be a long and ongoing process, involving procedural changes and cultural changes. In this article we’ll look at some things you can start doing immediately to gain some “quick wins” at your company.

Plan Quick Wins As Part of a Long-Term Process

Why do most New Year’s resolutions fail? It’s because most people try to implement change suddenly, immediately, and haphazardously, without having an underlying strategy or process.

When trying to change an organization’s processes and philosophy, you should remember that the actions you take today should be part of a deeper, longer-term strategy. Immediate actions are great, as long as they are part of a sustained push towards continual improvement.

There are a few dangers in attempting to implement organizational changes without having a broader plan:

  • You might alienate your technical team. If they are used to doing things “their way”, drastic attempts to change their behavior will likely alienate them and ultimately fail.
  • You might cause disruptions to projects and workflow. If you attempt to implement change too rapidly, your team will be confused and work quality will suffer, and this will probably be noticed by your clients.

Your attempts at quick wins should be focused on:

Demonstrating value to your clients. Improving your client’s experience and perception of your company is key to the differentiation process. You want to, above all, make sure your changes are positively influencing your clients’ experience.

Demonstrating value to your team members. The more you can show your team why your changes are valuable and necessary, the more likely it becomes that they will absorb those reasons and make them their own. You want to make it as painless as possible for your team to implement the changes.

Most of the quick wins we will look at will involve gathering information, whether from clients or from team members. This is usually the lowest-hanging and most valuable fruit. Asking questions and gathering information gets you clear on the direction you should be heading in and the steps you should be taking next.

Focus On Core Competencies

What does your company do best? What are your strengths? Having core competencies and a niche sets you apart from your competitors and gets you greater attention.

This can be counter-intuitive. At many companies (not just InfoSec companies), there can be the philosophy of: “Well, we have to do everything, because if we don’t do everything, we’ll miss some clients.” Or: “Our client just asked for this. We have to give it to them to make them happy.”

This leads to a marketplace where pentesting seems more of a generic commodity than it is. Your potential client may be looking at a line of near-identical InfoSec companies, all of whom claim to do everything. In such a marketplace, it can be hard to stand out.

Focusing on what you’re truly great at has several positive results:

  • You become known for being great at the specific systems and technologies at which you excel.
  • By voluntarily defining what you’re not good at, your perceived strengths become that much more believable.

In short, there is power in saying “No” to clients and defining your focus.

One example of how this can play out: If you define one of your core competencies to be SAP Security, then your client may not hire you to do an Android assessment. This may seem like a lost opportunity, and perhaps it is in the short-term.

But what will happen is that your clients and colleagues will remember what your focus is, and will respect that you have a focus and are willing to admit when something is not your specialty. Clients will be more likely to get in touch with you later when they have a problem that falls in your area of expertise. And, down the road, if you expand your core competencies to other technologies, your claims of expertise will be that much more believable and powerful.

Not only is this approach powerful for gaining respect from clients, it also gains you respect from talent you may be recruiting. Being known as a company that specializes in cryptography vulnerabilities, for example, will make it more likely that cryptography experts will want to work with you, which creates a positive feedback loop for your quality and reputation.

Quick Wins

Here are some beginning steps for establishing your company’s core competencies.

  1. Set up an internal meeting to brainstorm what your core strengths are, and how you want to position yourself in the marketplace.
  2. Ask, “Who are our ideal clients?” Getting clear about what clients make your team happy lead to realizations about what your strengths are.
  3. Ask, “Who are the clients we don’t want to serve?” Identifying the clients who aren’t right for you will help you adjust your messaging to speak to the right audience. This will create a self-selecting process, where your favorite work is attracted to you and your least favorite work is not.
  4. Research the industry to see what needs may be underserved. Can you think of a strength you have that not many companies are focused on serving?
  5. Talk to colleagues about your ideas for niche positioning. Ask for feedback about whether your ideas for positioning will be perceived as valid.
  6. Talk to new prospects as if you’ve already repositioned the company and gauge their response. For example, if you’re at a networking event, you might talk to new contacts using your new company messaging and focus, and see how they react, whether positively or with no interest. With methods like these, you can test client and industry response before acting implementing the change on a bigger scale.
  7. Talk to trusted clients and run your ideas by them. Ask questions like, “If we focused on this specific service, would this be valuable to you?”

Learn What Makes Clients Happy

As we talked about a bit in our first article, InfoSec companies can be a little out of touch with ideas of customer service. Often, companies are so focused on the project at hand and delivering the report on time, that client experience can be the last thing on your team’s mind.

But in order to differentiate and get noticed, your team, like it or not, will have to make strides in improving clients’ experience.

Part of the problem is that business owners will often make assumptions about what their clients value. You may assume that your clients value X, Y, and Z about your company. But unless you explicitly ask, you won’t know.

For example, maybe you think your clients value your technical expertise and professionalism, when the truth is that your clients value your ability to accommodate sudden changes in scheduling. Or maybe, above all else, they value a very clear Executive Summary section, which helps them make the case for IT security initiatives.

The point is: You shouldn’t assume anything about what makes your clients happy.

The first thing to do to get more clear in this area is to gather information from clients: information about what they value, what they don’t value; what works, what doesn’t work; what they like about your company specifically and what they don’t like. This information can then be used to:

  • Expose major failures in how your company is serving clients
  • Improve and standardize business procedures and pentesting methodologies
  • Decide on a new company focus (i.e., a core competency)
  • Improve the value and consistency of deliverables
  • Come up with new services (i.e., new ways to make money or add value)

Also, the nice thing about eliciting client feedback is that it helps you sell the necessary changes to your team members. If clients make it clear that they want to see changes, such communication is harder for everyone to ignore.

Quick Wins

Here are some starting steps for gathering much-needed client thoughts.

  1. Have a team meeting and think about the types of questions that would be valuable to ask your clients. Examples of valuable questions include:
  2. “How would you compare your experience with our company with your experiences at other companies?”
  3. For repeat clients: “How would you compare your most recent experience with previous experiences?”
  4. “How would you rate the value of our report?”
  5. “What would you like to see from our report that you didn’t?”
  6. What is the worst part of our reports?
  7. What is our weakest point compared to other vendors?
  8. “Have you recommended us in the past? Why or why not?”
  9. “What kinds of InfoSec services would you like to see offered but are not getting?”

For ease of use, you should try to make most questions Yes/No or a single-choice on a rating scale (e.g., a 1 to 10 scale). Requests for long responses are sometimes too much of a demand and don’t result in actionable information.

Here is an article with many examples of questions you can use to gather customer feedback. And here is an example survey, hosted with Google Forms, that you can copy and modify to hit the ground running.

  1. Using the most relevant questions, draft an email survey to send to existing and past clients. Store the responses to the survey in a format that is easy to share with your team in an ongoing manner (for example, an internal wiki).
  2. Start to create feedback loops in your delivery process for gathering client feedback. For example, you might put a section in the report template that asks them to click a link and fill out a feedback form. By making feedback-gathering part of your process, you ensure it will be done on every project.
  3. Set up a reward system for team members who get high evaluations from clients. (But don’t punish team members just because they don’t get high marks. Employee shortcomings, it has been shown time and time again, are almost always caused by a faulty process.)

Develop New Services

Your company’s relationship with your clients doesn’t end with the deliverable. But it may seem that way at many InfoSec companies, where everything is about completing a project and moving on to the next one.

Ideally, you want to be thinking of additional services that aid your clients’ understanding and deal with their vulnerabilities in an ongoing fashion. Adding additional services has a couple positive effects:

  • Services can be additional products and ways to make money.
  • They can be bundled with your existing pentesting services, as a way to provide added value and to justify your rates.
  • They differentiate you from your competitors.

Some ideas for additional services:

  • Offer clients a custom emailed newsletter that features information on security vulnerabilities for the specific technologies they use. For example, if your client uses WordPress and Magento, every month you deliver them updates and news on WP and Magento security issues. (This could be set up pretty easily in a content management system.)
  • Subscription services that allow your clients to get quick responses and input whenever they run into security problems or just want to bounce an idea off someone knowledgeable. This is essentially a support contract or retainer with guaranteed response time.
  • You could remove a common gap between discovery and remediation by providing vulnerability data in a format clients could upload directly into their bug tracker. (Of course, the format each client needs will depend on the specifics of their bug tracking system.)

These are just a few ideas for additional services.

Blue Ocean Strategy is a popular book about creating uncontested market space, and includes many ideas on how to differentiate offerings and create new services.

Quick Wins

Here are some starting steps for coming up with auxiliary, value-added services.

  1. Ask your team members for ideas on additional services.
  2. Check out competitors and see what they’re doing. Don’t copy them exactly (as the idea is, after all, differentiation) but use those ideas for inspiration.
  3. When polling your clients, ask them for additional feedback, such as: “If we started offering this additional service, would you find it valuable? Would you sign up for it? Would you pay x amount for it?”

Only the Beginning

The ideas in this article are only the beginning, of course. It can sometimes be a long road to change established processes and mindsets at any company. But hopefully we’ve given you some ideas for how to start today on improving the perceived value of your company and, by extension, set yourself apart from the pack.

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

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.

InfoSec Experience Is Not Enough…

If you work in the information security industry, you probably are already well aware of the growing competition and commoditization in the marketplace. Overseas companies and small consultancies are charging lower rates, which can make it hard for companies to show why their higher rates are justified.

The truth is that pure, technical experience is no longer enough. It may have been, a few years ago, when competition in our industry was low, but it’s not enough anymore. Even if you know for a fact that you have one of the best, most technically skilled InfoSec teams out there, it doesn’t mean anything unless you are communicating that to your potential clients.

This article (the first in a series) takes a look at some of the reasons behind the industry commoditization. It will also, hopefully, start you out on a journey of optimizing and standardizing your company’s methodology and client-facing communications.

Increasing Competition and Commoditization

You probably already know many of the factors leading to lower average rates in the industry, but here’s a quick rundown:

  • Overseas competition: There are a growing number of overseas InfoSec companies, almost all charging significantly lower rates than the rates of companies in developed countries.
  • Small companies: There are an increasing number of small InfoSec startups. Their lower overhead means they can charge lower rates.
  • Freelancers: Similarly, there are many freelancers (some perhaps are your ex-employees), doing jobs for lower-than-average rates.
  • Software applications: There are a growing number of pentesting applications and tools, which can serve to level the playing field a bit. More importantly, though, it makes it seem to potential clients as if pentesting is more of an interchangeable commodity than it actually is.

All of these factors are creating what has been called a “race to the bottom”. InfoSec companies who were having no problem charging their normal rates a few years ago are now feeling the pressure to match lower rates from competitors or overseas companies to keep their lights on.

For all of these reasons, it is no longer enough for an InfoSec company to be great. They must show and prove their greatness.

Proving Value to Clients

For many InfoSec companies, the concept of trying to communicate their strengths to clients is a foreign concept. So many InfoSec companies are focused almost entirely on staying up-to-date on technology and vulnerabilities, and working on their projects. This is understandable; the work is very important. Without high-quality work, nothing is possible.

But competing in this modern, highly competitive marketplace means you must find ways to show why the work is high-quality. For many InfoSec companies, this will mean making adjustments to their fundamental business philosophy. It will mean focusing, as an organization, on the many ways it’s possible to improve your processes and to showcase those processes.

A Cultural Shift

For many companies primarily focused on the projects right in front of them, this will be a complete cultural shift. An analogy could be made to the major cultural change that happened in American car manufacturing in the 1980s, as companies like Ford and General Motors realized it was necessary to emulate the philosophies of Continual Improvement used by Japanese industry. (If you’d like to learn more about those cultural changes, click here.)

In a similar way, InfoSec companies must adapt a new mindset focused on the client experience and client-facing communication.

Improving Processes

The biggest part of improving the client experience (and potential client experience) is in optimizing and standardizing your processes and procedures. A few examples of how process improvements will help you prove your worth to clients:

The Power of Consistency

Your methodology must be truly consistent. Many companies say things like: “Our process is standardized. We always do x, y, and z on every project we work on.” But in reality, there may be significant variance in methodology from project to project. Different team members and managers may work on every project, and they may have different methods and styles. The company may pay lip service to the idea of consistency, but it may not value it in practice.

Being truly consistent means setting that principle as a real requirement on every project.
* There have to be standards in place.
* Those standards and systems need to be clearly communicated to every team member.
* Managers must communicate why those systems are in place and why they are important.
* There must be concrete measures in place to ensure guidelines are maintained so that, if there is a problem with a project or with a team member’s performance, it can be spotted and addressed.

In many InfoSec companies, the culture will make this difficult. (And we’ll talk more about ways to overcome these cultural obstacles in a future article.) But process consistency is vital. Clients want to know what to expect when they hire you and rehire you; this is especially true for the biggest clients. Consistent processes will demonstrate to your clients (especially your repeat clients) that you value consistency. And with greater consistency, it will be easier to demonstrate what exactly makes your team valuable.

The Power of Reports

Most InfoSec companies understand that reports are valuable, but they don’t truly understand just how valuable. A report is not just a way to communicate technical vulnerabilities and assessments. It is an opportunity. A report can be an opportunity to:

Showcase your consistent processes: If your methodology and business processes are fantastic, and consistent, then a report is a way to showcase your methods and how you thoroughly arrived at your results. You must find a way to work your methodology cleanly into your reports. And you must find a way to make that a part of your process that happens every time.

Proving the right team was on the job: Clients want to feel assured that you have the best people on the job. Reports are an opportunity to show to clients that the people working on their project are highly qualified. (We’ll talk more about the importance of this perception in a future article.)

Get repeat business: When you send deliverables, you are also, indirectly, pitching a client on future work. A report can showcase the benefits of your methodology, which can be a convincing sales message in itself. The report can also communicate the benefits of regular testing to make sure pentesting catches new vulnerabilities. For example, your team might notice problems outside of the scope of the investigation; the report is an opportunity to point out those issues and recommend future responses.

Collaboration and reporting platforms are becoming more and more a must-have for InfoSec companies. These programs help ensure all team members are on the same page and speed up your reporting process. They also make it easier for certain types of communications to wind up in your reports every time, which is important for showcasing your consistency.

The Power of Customer Service and Follow-up

For many InfoSec companies, the idea of customer service is foreign. Following up with clients, or asking for feedback on projects, may not be part of a company’s culture.

But this will need to change if a company wants to be optimally competitive. Companies will need to focus more on the client experience. Managers will need to communicate to team members why customer service is valuable, and what “customer service” means in our project-based, extremelytechnical industry. Clients will need to be prompted for criticisms (and, concurrently, testimonials) so that processes can be continually improved.

Managers and employees must understand that asking for feedback, and ensuring client happiness, is not a “soft” side of the business. Getting feedback from clients is part of a process of continual improvement. Without knowing what makes clients satisfied or frustrated, it’s impossible to improve your service. Or, more importantly, the perception of your product.

These are the same philosophies that helped Japanese auto manufacturers climb to dominance after World War II: a continual focus on their users’ experience and a continual focus on process improvement.

Change Is Possible

At this point, you might be thinking something like, “These are all great, lofty ideas, but you have no idea what it’s like at my company. These things would be impossible to implement here.”

But process improvements and cultural improvements are always possible. It doesn’t matter if you’re a manager or owner trying to implement a top-down improvement process, or a team member trying to convince the higher-ups that there’s a better way of doing things. Change is possible; it will just require intelligent planning and, sometimes, patience and persuasion.

In the coming articles in this series, we’ll be looking at some specific strategies and tips you can start putting in place immediately. These strategies will help you optimize your processes and differentiate your company from your competitors. We will also focus on helping you prove the value of these ideas to your own team, because that is often the most important and difficult part of any institutional 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 soon.

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.

Going Freelance

Thinking of going freelance but not sure if it’s for you? Here are a few things that I think are worth considering before you take the plunge.

First, are you sure you actually want to go freelance? Is it that you want to be your own boss and manage your own work/life balance or is it just the lure of what, on the surface, appears to be good money and short hours?

I’ve been working for myself on and off for the last eight years so have quite a bit of experience of the advantages, disadvantages and things to consider when making the jump and in this article I’ll cover some of these. I hope they will be helpful to those of you thinking of making the jump or who have recently made it. A short disclaimer though, these are my experiences and opinions, they may not work for everyone and others may disagree but they will at least give you one point of view.

First off, back to the original question, do you really want to work for yourself? On the face of it, freelancers have a great life, the money is good, you can chose when to work, pick your clients and generally have a great time. The reality is that all this can be true but it takes effort, you have to put a lot of work in to get there and to stay there. Clients do not simply come banging on your door and while the daily rate can be very good you are unlikely to be working 5 days a week every week so don’t forget, you have to average that rate out over the month and year.

Here are some other things worth thinking about.

Hours

I find that I work a lot more hours working for myself than I ever did working for someone else. There are lots of reasons for this:

  • You are now running a business so have to do “business stuff” as well as the actual client work – Things like bank reconciliation, marketing/adverting and VAT returns all take time that isn’t billable so ends up being fitted in around jobs, usually in the evenings or weekends during busy periods.
  • Quality of work/reputation – Not that I didn’t care about the quality of work when I was employed but now the business is just me and the next job with a client is likely to be based on the deliverables from this job, I feel an extra pressure to do the best job possible, even if that means putting in a few extra hours. I also end up knowing the client at a more personal level as I’ve often been involved with the whole process from initial contact to final delivery and so want to deliver a higher quality product.
  • There is often no one there to stop you doing the extra hours – When working in an office the end of the day is obvious as everyone else is packing up and leaving but working on your own it is easy to get sucked into a job and lose track of time. This applies to employed people who work from home as well so not just freelancers.

Clients

Unless you are really lucky and are well known or have very specialist skills, it is unlikely that clients will simply come to you and so you’ll need to go out and win them in some way. When starting out you need to be careful how you do this. Most companies have a clause in their contract that stops you approaching any of their clients if you leave so don’t assume that if you are friendly with some of the company’s clients that you will be able to lure them away. You may also have to be careful signing up your own clients while still employed, this may breach your contract. If this is the case you may start your freelance career without any fully signed up clients which isn’t a good position to be in.

When working out where to get clients from there are a couple of options, go direct to companies and try to sell them your services or work through middlemen who resell your services for you. Which you choose is up to you and how you would rather work. Going direct to companies can be more lucrative as you get to negotiate for yourself and keep all the cash but doing this requires you to put effort in finding and winning these clients. Back to the hours worked, this isn’t billable work and you have to fit it in around paying clients. Working through a middleman means you don’t have to worry about sales and marketing and all the client schmoozing but means you lose a cut of the final invoice to the middleman.

I personally prefer using a middleman, actually a number of them, as I really don’t like having to do sales work and so am happy to give them their cut to do the work I don’t enjoy. Something I do consider here though is that if the middleman goes on holiday or has a bad month then I’ll not be getting any work that month. That is why I like to have a number of agencies that I work through as one may be on an ebb while the other is on a flow.

Until it has happened once, most freelancers don’t think about clients not paying, you just assume that you’ve done the job so the cash will come in, hopefully on time. I’ve had a couple of clients not pay, the first one hit me so badly that I ended up going back to employment as I couldn’t cover it. Telling friends their response is often “take them to court, sue them”, that is easier said than done when you find out that they haven’t paid because they’ve blown all their cash and have nothing left to pay anyone. Legal action can cost a lot of money and you are unlikely to be high on the list to get cash back if they are going belly up. Make sure you think about this and have reserves in case it happens.

Software/Hardware

As an employee you are most likely provided with all the hardware and software you require to do your job. You’ll get a laptop, Nessus licence, that kind of thing. When you are on your own you have to provide all that yourself. While a lot of security tools are free there are some instances where the commercial versions are really the best ones to choose. Make sure you add all these costs to your budget. Don’t forget the non-security tool software costs as well, a Windows licence (even if just used in a VM), Office and all the other little apps that you used to just install off the main app server without worrying about licences for.

Laptops, phones and other hardware – are you going to share your personal kit with the business or are you going to get it its own dedicated set? Duplicating it all is expensive but means you can do extra hardening on the work equipment and ensure it is only used for work to lessen the risk of exposing client data.

Also consider hardware redundancy, when employed, if your laptop dies the night before a test you might be able to acquire a replacement from a colleague and if not then you can probably hand off to the project manager talking to the client and postponing the job. When you are on your own all that becomes your responsibility. I’ve been a Linux user for over 10 years but my main laptop has been running Windows 7 for over a year because I’ve not had time to take it out of service for long enough to reinstall it. I have a backup machine that I can use if I need to but being older it is a much lower spec so even when I’ve had a few days spare I haven’t risked making the swap just in case.

Legal Issues

The contract

This section could also be called Cover Your Ass and you need to give it close attention. What you need is dependent on your location and the jobs you are doing but here are the basics.

First you really should get a good contract. There are lots of contracts floating around on the net which you could take and either use as is or modify to your own requirements. This is the cheap option but not one that I went for. The reason I chose not to do it is that I wanted to know that my contract matched my business and the jobs I was doing. The contract is the thing that decides who is in the right if things go wrong, I was happy to spend money and time with a good lawyer to make sure mine was as good as I could get.

There are also a number of potential problems with random contracts found on the net:

  • It could be out-of-date – Laws and regulations change
  • Location – The contract may not be for your country/jurisdiction
  • The contract may have flaws or may simply be written by someone who was not a lawyer and just thought the words sounded good

Insurance

In terms of insurance, some may be mandatory, some may be recommended and some may be personal preference. As with contracts, what you need will be based on the kind of work you are doing and where you are doing it. The different types I’d definitely look at are:

  • Professional indemnity – Covers you if you make a mistake while on a job
  • Public liability – In case someone gets hurt as a result of you doing a job
  • Income protection – If for some reason you are unable to work there will be no money coming in, this can help in this kind of situation

When getting insurance, make sure you explain exactly what it is you will be doing to the insurance company or broker. I went through a few companies who turned me down straight till I got annoyed and asked one for an explanation as to why they wouldn’t cover me. After a discussion they realised they didn’t fully understand the job I initially described to them so changed their minds and covered me. This was quite a few years ago and as the industry has grown there are now many more options out there and companies understand the profession better but I’d still make sure you fully explain to them what it is you will be doing just in case.

Training

It’s all down to you, if you want training you have to pay for it yourself in time and money. There are a lot of free, or very cheap, courses out there and you can learn a lot from just reading articles but back to hours worked again, it isn’t billable work so you have to fit it in around your paying clients.

Holidays

No holiday pay, if you aren’t working you aren’t earning! You don’t even get paid for bank holidays.

I like to tie training and conferences with holidays, our family holiday last year started in Gent at BruCON then moved on to a more normal holiday.

Money

I can’t lie, the money as a freelancer, on the face of it, is a lot better than as an employee but, when you add in all the extra hours you’ll end up working, the lack of holiday pay, having to provide all your own hardware, software, stationary (I still send letters occasionally) and all the other non-billable things you need to do and buy it doesn’t necessarily work out that much better.

When working out your budgets don’t assume that you’ll set your day rate at X and will get 253 * X (253 is the number of working days 2013). Make realistic assumptions about how much work you think you’ll get on a good and bad month and then decide if it looks as good as it did.

Think about what will happen if you have a couple of bad months back to back, can you survive?

Conclusions

I love being freelance. I much prefer the freedom it gives, especially with two small children at home, but I’m lucky that I have a lot of very good clients and I’m able to sit at my desk from 9-5 (or however long a job takes) without getting distracted. I take regular breaks and will take a day off just to play with the kids if work is quiet but I’ll also get my head down and barely leave my office when work is there.

If you are thinking about it, make sure you look at the unglamorous side of it as well as fun looking public side and if you decide to do it, good luck, I hope you enjoy it as much as I do.

About Robin Wood

Robin is a freelance pen-tester, researcher and developer. Among his projects are Karma, KreiosC2 and Jasager. He is based in the UK.

Find him on Twitter as @digininja or at www.digininja.org

Writing a security report: the elements of a useful pentest deliverable

We have discussed that the security report produced at the end of the engagement is a key component in proving your worth to your current and future clients.

When crafting a pentest report not only you’ll have to think about what to include in the report (sections, contents, tables, stats) but you will also need to decide how to write it. Let’s review what it takes to create a useful pentest report.

We are not talking about the specifics or the differences in structure between the deliverable produced for different project types (e.g. VA vs. wifi vs. external infrastructure). We want to provide you with the high-level guiding principles that you can use to ensure that the final security report you produce and deliver to your clients is a useful one.

The recommendations in this piece are based on dozens of report templates that we’ve seen as part of our report customisation service for Dradis Pro as well as our experience in the industry.

The goal of the engagement

The security report produced after each engagement should have a clear goal. In turn, this goal needs to be aligned with the client’s high-level goals. In “Choosing an independent penetration testing firm” we saw how identifying the goals and requirements of an engagement is a real pain point for some clients but also an opportunity for the security firm to provide education and guidance to strengthen the partnership with their customers.

A typical goal as stated by the client could be: “our objective is to secure the information”. This can be a good starting point albeit somewhat naive in all except the most simple cases. These days systems are so complex that assessing the full environment is sometimes not realistically possible (due to time on budget constraints). A more concrete goal such as “make sure that traveller A can’t modify the itinerary or get access to traveler B’s information” would normally produce a better outcome.

However, for the sake of this post, let’s keep it simple and focus on the broader goal of “securing the information”. With that in mind, the goal of the security report needs to be to communicate the results of the test and provide the client with actionable advice they can use to achieve that goal. That’s right, we need to persuade our clients to act upon the results we provide them.

In order to help your client to meet their goals, the more you know about them and their internal structures and processes the better. Who commissioned the engagement? Why? Is there a hidden agenda? Familiarising yourself with their industry and domain-specific problems will also help to focus your efforts on the right places.

Finally, it is important to know the audience of the deliverable you are producing. This seems like an obvious statement, but there is more to it than meets the eye. Who do you think is going to be reading the report your firm has produced? Is this going to be limited to the developers building the solution (or the IT team managing the servers)? Unlikely. At the very least the development manager or the project lead for the environment will want to review the results. Depending on the size of the company, this person may not be as technical as the guys getting their hands dirty building the system. And maybe this person’s boss or their boss’ boss will be involved. If your results expose a risk that is big enough for the organisation, the report can go up the ladder, to the CSO, CTO or CEO.

One security report, multiple audiences

At the very least it is clear that we could have multiple audiences with different technical profiles taking an interest in your report. If there is a chance that your deliverable will end up making the rounds internally (and the truth is that this is always a possibility), the wrong approach to take is to either produce a completely technical document full of nitty-gritty details or, going to the other end of the spectrum, delivering a high-level overview with the summary of the highlights of the test apt for consumption by C-level execs but lacking on technical depth.

The easiest way to find the middle ground and provide a useful document for both the technically inclined and also to the business types among your readers is to clearly split the document into sections. Make these sections as independent and self-contained as possible. I like to imagine that different people in the audience will open the document and delete the section they are not interested in and they will still get their money’s worth of value on what remains.

Problems you don’t want to deal with

Before delving into what to include and how to structure it, there are two problems you don’t want to deal with during the reporting phase of the project: collation and coverage.

Collation

It is still quite common that a sizable amount of the reporting time allocated during a test is spent collating results from different team members.

As we saw in the “Why being on the same page matters?” post, there are steps you can take to minimise the amount of collation work needed such as the use of a collaboration tool during the engagement.

Reporting time shouldn’t be collation time. All information must be available to the report writer before the reporting time begins. And it must be available in a format that can be directly used in the report. If your processes currently don’t make this possible, please consider reviewing them as the benefits of having all the information promptly available to the report writer definitely outweigh the drawbacks involved in updating those processes.

Coverage

How good was the coverage attained during the testing phase of the engagement? Was no stone left unturned? Do you have both evidence of the issues you uncovered and proof of the areas that were tested but were implemented securely and thus didn’t yield any findings? If not, the task of writing the final report is going to be a challenging one.

We have already discussed how using testing methodologies can improve your consistency and maximise your coverage raising the quality bar across your projects. Following a standard methodology will ensure that you’d have gathered all the evidence you need to provide a solid picture of your work in the final deliverable. Otherwise, the temptation of going down the rabbit hole, chasing a bug that may or may not be there may become too strong. We’ve all been there, and there is nothing wrong with it, as long as it doesn’t consume too much time and enough time is left to cover all the areas of the assignment. If you fail to balance your efforts across the attack surface, this will be reflected in the report (i.e. you won’t be able to discuss the areas you didn’t cover) and it will reflect badly on your and your firms’ ability to meet your client’s expectations.

Security report sections

For the rest of this post, we will assume that you have been using a collaboration tool and are following a testing methodology during the testing phase and as a result, you’ve got all the results you need and have attained full coverage of the items under the scope of the engagement.

The goal of this post is not to provide a blow-by-blow breakdown of all the possible sections and structure you need to provide, there are some comprehensive resources on the net that go beyond what we could accomplish here (see Reporting – PTES or Writing a Penetration Testing Report). We want to focus on the overall structure and the reasons behind it as well as the approach and philosophy to follow when crafting the report to ensure you are producing a useful deliverable. At a very high level, the report content must be split between:

  • Executive summary
  • Technical details
  • Appendices

Executive summary

This is the most important section of the report and it is important not to kid ourselves into thinking otherwise. The project was commissioned not because an inherent desire to produce a technically secure environment but because there was a business need driving it. Call it risk management or strategy or marketing, it doesn’t matter. The business decided that a security review was necessary and our duty is to provide the business with a valuable summary.

The exec summary is probably the section that will be read by every single person going through the report, it is important to keep that in mind and to make sure that it is worded in a language that doesn’t require a lot of technical expertise to understand. Avoid talking about specific vulnerabilities (e.g. don’t mention cross-site request forgery) and focus on the impact these vulnerabilities have on the environment or its users. The fact that they are vulnerable to X is meaningless unless you also answer the question “so what?” and explain why they should care, why it is a bad thing and why they should be looking into mitigating the issue. As Guila says in the article, why give a presentation at all if you are not attempting to change the audience’s behaviors or attitudes?. And the security report is most definitely a presentation of your results to your client.

Don’t settle for just throwing in a bunch of low-end issues to the conclusions (e.g. “HTTPs content cached” or “ICMP timestamps enabled”) just to show that you uncovered something. If the environment was relatively secure and only low-impact findings were identified, just say so, your client will appreciate it.

Frame the discussion around the integrity, confidentiality, and availability of data stored, processed and transmitted by the application. Just covering the combination of these 6 concepts should give you more than enough content to create a decent summary (protip: meet the McCumber cube).

Apart from the project’s conclusions and recommendations, it is important that this section contains information about the scope of the test and that it highlights any caveats that arose during the engagement. Again this is to correctly frame the discussion and give the readers that may not be as familiar with the particular environment (e.g. CSO) the appropriate context.

In addition, it offers you protection should the client decide to challenge your results, approach or coverage attained. If a host or a given type of attack was requested by the client to be out of scope, this needs to be clearly stated. Along the same lines, if there were important issues affecting the delivery (e.g. the environment was offline for 12 hours) these have to be reflected. There is no need to go overboard on this either, if the application was offline for half an hour on the first day out of a five-day test and you don’t think this had an impact (e.g. you were able to do something else during that time or managed to attain full coverage throughout the rest of the test), there is no point in reflecting it on the report.

Technical details

This is the area that should be easier to craft from the tester’s perspective. There is not much to add here other than trying to keep your entries relevant to the current project. For instance, don’t include any MSDN references explaining how to do X in .NET when the application is written in Java. Or don’t link to the Apache site if all servers are using IIS.

I don’t want to get into the scoring system for the vulnerabilities because that could add a few thousand words to the post, just pick a system that works for you and your clients and try to be consistent. This is where having a report entry management system in place (*cough*, like VulnDB) can help maintain consistency of language and rating across projects and clients, especially for larger teams.

A final note on what to include on each finding: think about the re-test. If six months down the line, the client comes back and requests a re-test, would any of your colleagues be able to reproduce your findings using exclusively the information you have provided in the report? You may be on holiday or otherwise unavailable during the re-test. Have you provided enough information in the first place? Non-obvious things that usually trip you over are details about the user role you were logged in as when you found the issue or remembering to include the series of steps you followed from the login form to the POST request that exposed the issue. Certain issues will only be triggered if the right combination of events and steps is performed. Documenting the last step in the process doesn’t usually provide a solid enough base for a re-test.

Finally, remember that the purpose of the document is not to show how smart you are or how many SQLi techniques you used. Everything needs to be weighed and measured against the engagement goals and the business impact to the client. For instance, an unglamourous absence of account lockouts in the client’s public facing webapp is likely to have a bigger impact for their business and users than a technically brilliant hack that combined path traversal, command execution and SQLi in backend admin interface only reachable by IT administrators over a secure VPN link.

Appendices

The Appendices should contain the information that while not key to understand the results of the assessment would be useful for someone trying to gain a better insight into the process followed and the results obtained.

An often overlooked property of the Appendixes section is that it provides a window to the internal processes followed by the testing team in particular and the security firm in general. Putting a bit of effort into structuring this section and providing a more transparent view of those processes would help to increase the transparency of your operations and thus the trust your clients can place on you. The more you let them see what is going on behind the curtain the more they’ll be able to trust you, your team and your judgment.

In the majority of the cases, this additional or supporting information is limited to scan results or a hodgepodge of tool output. This is fine as it will help during the mitigation and re-test phases but there are other useful pieces of information that can be included. For instance, a breakdown of the methodology used by the team is something that you don’t see that often. I’m not talking about a boilerplate methodology blob (i.e. ‘this is what we normally do on infrastructure assessments’), but a real breakdown of the different areas assessed during this particular engagement along with the evidence gathered for each task in the list to either provide assurance about its security or reveal a flaw. This will show that your firm is not only able to talk the talk during the sales and pre-engagement phases but that your team, on a project-by-project basis, are walking the walk and following all the steps in the methodology. Providing your clients with this level of assurance is going to automatically set you ahead of the pack because not a lot of firms are capable (or willing) to do so.

tl; dr;

Understanding the project goals, realising that the security report you are crafting will have multiple audiences of different technical expertise, making sure that the deliverable reflects not only the issues uncovered but also documents the coverage attained and the process involved in doing so will go a long way towards producing a useful pentest deliverable. Couple that with enough technical information to provide the project team with sufficient knowledge on the issues uncovered, the best mitigations to apply and a means to verify their reviewed implementation and you will have succeeded in your role of trusted security advisor.