4 habits from consulting every security professional should steal

After being home with paternal leave 80% of the weak and working 20% of the week, I will be switching percentages from tomorrow. That means more time to get hands-on with security. I’ve recently switched from risk management consulting to a pure security position within a fast-growing organization with a very IT-centric culture. Working one day a week in this environment has been great to get an impression of the organization and its context, and now the real work begins. I think habits from the consulting world will be beneficial to everyone involved. Here’s how.

 

sec_pic_habits_consulting

Successful consultants must not only be good at what their technical area of expertise is, but also at moving around in unknown territories in client organizations while navigating complex issues with many stakeholders – these are habituated skills that security professionals should adopt.

 

Slipping into someone else’s shoes

Consulting is about understanding the unarticulated problems, and getting to the core through intelligent questions. That is the essence of it; the good consultant understands that context is everything, and that the perception of context is different depending on the shoes you wear. This goes for strategy development, for risk management in general, in definitely for cybersecurity.

Use your analytics for (almost) everything

As a consultant you must be able to back up your claims. Your recommendations are expensive to get, and they’d better be worth the price. Often you will create recommendations that will be uncomfortable to decision makers – due to cost, challenged assumptions or that your recommendations are not aligned with their gut feeling.

This is why consultants must be ready to back up their claims, with two essential big guns; a convincing approach to analysis, and solid data. Further, to add to the credibility of the recommendations, the methods and data should be described together with the uncertainties surrounding both.

Working in security means that you are trying to protect assets – some tangible, but most are not. The recommendations you make usually carry a cost, and to convince your stakeholders that your recommendations are meaningful you need to provide the methods and the data to make them compelling. Which brings us to the next step…

Always make an effort to communicate with purpose

Analysis and data become useless without communication. This is the high-stakes point of consulting, communicating with clients, stakeholders, internal and external subject matter experts. Not only for presenting your facts but as a support for the whole process. Understanding context is never a one-way street; it is a multifaceted, multichannel communication challenge. Understanding data and uncertainties often require multidisciplinary input. This requires questions to be asked, provocations to be made and conversations to be had. Presenting your recommendations requires public speaking skills. And following up requires perseverance, empathy and prioritization.

In cybersecurity you deal with a number of groups, each with their own perspectives. Involving the right people at the right time is key to any successful security program, ranging from optimizing automated security testing during software integration to teaching support staff about social engineering awareness.

And that leaves one more thing: learning

If there is one thing consulting teaches you, it is that you have a lot to learn. With every challenge you find another topic to dive into, another white spot in your know-how. Consultants are experts at thriving outside their comfort zones – that is what you need to do to help clients solve complex issues you have never seen before. You must constantly reinvent, you must constantly remain curious, and you must process new information every day, in every interaction you have.

Cybersecurity requires learning all the time. One thing that strikes me when looking at new attack patterns is the creativity and ingenious engineering of bad guys. Not all attacks are great, not all malware is complex, but their ability to distill an understanding of people’s behaviors into attack patterns that are hard to detect, deny and understand is truly inspiring; to beat the adversaries we can never stop learning.

Security Awareness: A 5-step process to making your training program role based and relevant

Security awareness training is one of many strategies used by companies to reduce their security risks. It seems like an obvious thing to do, considering the fact that almost every attack contains some form of social engineering as the initial perimeter breach. In most cases it is a phishing e-mail.

Security awareness training is often cast as a mandatory training for all employees, with little customization or role based adaptation. As discussed previously, this can have detrimental effects on the effectiveness of training, on your employee’s motivation, and on the security culture as a whole. Only when we manage to deliver a message adapted to both skill level and motivation levels we can hope to be successful in our awareness training programs: When does cybersecurity awareness training actually work?

So, while many employees will need training about identification of malicious links in e-mails, or understanding that they should not use the same password on every user account, other employees may have a higher level of security understanding; typically an understanding that is linked to the role they have and the responsibilities they take. So, while the awareness training for your salesforce may look quite similar to the awareness training you give to your managers and to your customer service specialists, the security awareness discussions you need to have with your more technical teams may look completely different. They already know about password strength. They already understand how to spot shaky URL’s and strange domains. But what they may not understand (without having thought about it and trained for it) is how their work practices can make products and services less secure – forcing us to rely even more on awareness training for the less technically inclined coworkers, customers and suppliers. One example of a topic for a security conversation with developers is the use of authentication information during development and how this information is treated throughout the code evolution. Basically, how to avoid keeping your secrets where bad guys can find them because you never considered the fact that they are still there – more or less hidden in plain site. Like this example, with hardcoded passwords in old versions of a git repository: Avoid keeping sensitive info in a code repo – how to remove files from git version history

So, how can you plan your security conversations to target the audience in a good way? For this, you do need to do some up-front work, like any good teacher would tell you that you need to do for all students; people are different in terms of skills, knowledge, motivation for compliance, and motivation to learn. This means that tailoring your message to be as effective as possible is going to be very hard, and still very necessary to do.

The following 5-step process can be helpful in planning your content, delivery method and follow-up for a more effective awareness training session.

training_personal_targeting

A 5-step process for preparing your awareness training sessions. 

First you need to specify the roles in the organization that you want to convey your message to. What would be the expectations of the role holders of a good security awareness training? What are the responsibilities of these roles? Are the responsibilities well understood in the organization, both by the people holding these roles, and the organization as a whole? Clarity here will help but if the organizaiton is less mature, understanding this fact will help you target your training. A key objective of awareness training should here be to facilitate role clarification and identify expectations that are always exisiting but sometimes implicitly rather than explicitly.

When the role has been clarified, as well as the expectations they will have, you need to consider the skillsets they have. Are they experts in log analysis from your sys.admin department? Don’t insult them by stressing that it is important to log authentication attempts – this sort of thing kills motivation and makes key team members hostile to your security culture project. For technical specialists, use their own insights about deficiencies to target the training. Look also to external clues about technical skill levels and policy compliance – security audit reports and audit logs are great starting points in addition to talking to some of the key employees. But remember, always start with the people before you dive into technical artefacts. And don’t over-do it – you are trying to get a grasp of the general level of understanding in your audience, not evaluate them for a new job.

The next point should be to consider the atmosphere in the group you are talking to. Are they motivated to work with policies and stick with the program? Do they oppose the security rules of the company? If so, do you understand why? Make sure role models understand they are role models. Make sure policies do make sense, also for your more technical people. If there is a lack of leadership as an underlying reason for low motivation to get on board the security train, work with the senior leadership to address this. Get the leadership in place, and focus on motivation before extra skills – nobody will operationalize new skills if they do not agree with the need to do so, or at least understand why it makes sense for the company as a whole. You need both to get the whole leadership team on board, and you probably need to show quite some leadership yourself too to pull off a successful training event in a low motivation type of environment.

Your organization hopefully has articulated security objectives. For a more in-depth discussion on objectives, see this post on ISO 27001. Planning in-depth security awareness training without having a clear picture of the objectives the organization is hoping to achieve is like starting an expedition without knowing where you are trying to end up. It is going to be painful, time-consuming, costly and probably not very useful. When you do have the objectives in place – assess how the roles in question are going to support the objectives. What are the activities and outcomes expected? What are the skillsets required? Why are these skillsets required, and are they achievale based on the starting point? When you are able to ask these questions you are starting to get a grip not only on the right curriculum but also on the depth level you should aim for.

When you have gone through this whole planning excercise to boil down the necessary curriculum and at what level of detail you should be talking about it, you are ready to state the learning goals for your training sessions. Learning goals are written expressions of what your students should gain from the training, in terms of abilities they acquire. These goals makes it easier for you to develop the material using the thinking of “backwards course design“, and it makes it easier to evaluate the effectiveness of your training approach.

Finally, remember that the training outcomes do not come from coursework, e-learning or reading scientific papers. It comes from practice, operationalization of the ideas discussed in training, and it comes from culture, when practice is so second nature that it becomes “the way we do things around here”.

To achieve that you need training, you need leadership, and you need people with the right skills and attitudes for their jobs. That means that in order to succeed with security the whole organizaiton must pull the load together – which makes security not only IT’s responsibility but everybody’s. And perhaps most of all, it is the responsibility of the CEO and the board of directors. In many cases, lack of awareness in the trenches in the form of no secure dev practices, bad authentication routines, insufficient testing stems from a lack of security prioritization by the board.


Want more? Get free updates by joining the Safecontrols e-mail list!