Security is just one part of a process for enabling information projects. However, it has become one of the most vital components to their success. This is why InfoSec expertise has been in demand for some time, and its stock is very high at the moment. I cannot see anything on the horizon that will change this.
Even so, security has to fit within a framework for achieving business-driven results: security experts must adapt their approaches and ways so their input can be understood and acted upon. This puts the onus back upon us. We’ve spent a lot of time learning about security, but not necessarily applying our knowledge to successful projects. There is a recognition that the ability to successfully channel our understanding is just as important as the knowledge itself. At least one major InfoSec credentialing scheme has built in Skills for the Information Age (owned by the SFIA Foundation) to its process for certifying security professionals. SFIA “describe[s] professional skills at various levels of competence.” [and]. “. generic levels of responsibility, regarding Autonomy, Influence, Complexity, and Business Skills”.
As with security, being taught about a business process framework such as PMBOK (i.e. the Project Management Body of Knowledge) is not the same as applying it. A problem for InfoSec professionals is that some of these business project frameworks are just as hard for us to grasp as it can be for non-security project managers to understand our art. Let me be frank: attending a one-day seminar in the 1990s on a business management framework (not PMBOK) must rate as one of the most mind-numbing experiences of my career, and I learnt nothing that I could apply. Looking back, I wish I’d just spoken out and said it would have been more valuable to have run some desktop exercise than endure a whole day’s PowerPoint (even though that was a novelty then).
At around the same time I was struggling with dry business management theory, I heard about a member of my team whom project managers were always seeking out, even though this person was not at the top league of security knowledge. I was curious about this. It turned out that the team member was widely acknowledged as quick to grasp what a project was trying to do (so, to use SFIA terms, was demonstrating “business skills”) as well as the roles of the other project participants (i.e. under SFIA: demonstrating a grasp of “complexity”). They then applied their understanding – even without a mastery of InfoSec – and worked diligently with their more skilled colleagues to clear the security hurdles (SFIA might say this demonstrated both “influence” and “autonomy”). They had just an average understanding of project management too: but when this was put alongside their average understanding of security, the two halves made up a most effective whole. In short they had average knowledge but were demonstrating above average social and ‘soft’ skills. By this, I mean the ability to work effectively with a range of people to produce practical solutions.
Social and soft skills are not necessarily teachable or even conscious. However, when present they can increase understanding, cooperation and trust, and ultimately lead to more positive results. So why are they not spoken of more in InfoSec?
From my experience I can suggest a few reasons:
- The sheer complexity of InfoSec and the sometimes competitive nature between its professionals can create anxiety to impart knowledge among practitioners. We are, after all, sought out for our valued knowledge. Against this background, it can be personally challenging to draw the line between demonstrating that, yes, we are worth the investment put in us and just achieving successful outcomes through cooperative effort.
- InfoSec professionals are used to seeing issues presented as problems, e.g. people misusing privileges, data being stolen, altered or even held hostage. It is very easy for a mindset of “the problem with (such and such a solution) is…” to get inside the project we are meant to be supporting. If not handled well, security itself can then seem to look like a problem whenever solutions are needed.
- InfoSec people are not noted for their boardroom skills. Sometimes this is because we have technical knowledge that can seem to set us apart from the world of high-level decision making.
Ethical Hacking Training – Resources (InfoSec)
I don’t want to suggest that security specialists should enhance their project skills by just throwing away their InfoSec knowledge and applying people-watching principles. This is not the case: information specialists have knowledge that is unique, and I point out again the strong market for these skills. However, InfoSec professionals, like all managers, sometimes need to look at their comfort zone to try to see what is happening in other areas in which project team members may be quietly struggling. Also, taking things a step further (and demonstrating “autonomy” under the SFIA definition) we should try to look at the paperwork to question what’s going on in a project, based on a shrewd assessment of human behaviors and our experiences. It’s not possible to list all of the insights that this sort of view might reveal, but here are a few I’ve encountered:
- Why does a particular project component always seem to have really good excuses for late delivery? Is someone just good at making excuses?
- What is the true effect upon a team of shared responsibility for one deliverable? Perhaps everyone agreed at the outset that joint working seemed a good, time-saving and pragmatic solution: but maybe this is opening up threats to delivery?
- Why do the expected outcomes of a project always seem so very different from the original projections? Is the project still on course or is it slipping around so much that its outcomes will be unrecognizable (and irrelevant) to its sponsors?
- Why are the meetings always overrunning? There are plenty of good jokes about this scenario, but it can also indicate things are getting too complex and perhaps are not being delegated effectively.
- Sometimes, of course, InfoSec people will be the sharpest blade within an indifferent project. This can create a risk that you may end up doing things beyond your remit. This would very likely be cause for high-level intervention, and security professionals should not stay quiet if they find a lack of project governance is endangering a project.
So how is it possible to explain InfoSec problems to non-initiates without it sounding exactly like a problem? I think it’s all about demonstrating a commitment to keeping up the momentum of the project, though without necessarily giving in to pressure by agreeing to bad security. Project planners will usually appreciate your word on how long a security solution is likely to take to solve and how much it will probably cost, rather than hearing the full details. However, when the need to share this information becomes unavoidable, for instance because of the threat of serious delay, then use those soft skills to make a good case for security. After all, that is why InfoSec people are in demand!