A Security Officer’s Playbook

I've been writing some pieces for InfoSec Review about my past work in information security management and assurance within the British government. Although working in Whitehall meant taking responsibility for valuable state data, I have emphasized throughout that the principles of protective security are universal, and that lessons I learnt there can be usefully adapted anywhere.

Working for government has its privileges, but the institution is not markedly different from big corporations or, in the day to day running of many of its services, smaller organizations. As I have said, one big difference – which I did my best to make smaller – is the attitude to risk management. Governments do not want to be embarrassed because the stakes of a dent in their reputation are bigger than simple product or contract competitiveness. Governments risk losing credibility and, at the furthest extreme, their power if they are seen to mishandle things the electorate consider important.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

That risk-averse stance was not universal, but was difficult to overcome. This is partly due to some top heavy command chains inside government, where any part of the chain that fears the consequences of a risk can ensure that risk is not taken. Government workers tend to be generalists at most levels and, since the stakes can be quite high, they tend to seek consensus. Governments also usually have resources to buy in any perceived gaps in their expertise. So consultants have much to be grateful to government for, but their opinions can add layers of doubt into any risk management process. In the worst cases this can cause the decision making process to stall, like barnacles on a ship's hull.

It's against this background that government security officers have to make information security work. I have less experience in working in the private sector, where the dynamics are somewhat different. They are less averse to taking risks and rely on fewer internal voices to reach consensus. However, working in the public sector has certain advantages that are not confined to job security. I had always felt that private sector security staff always looked favorably on the government way of doing things, in particular over the attention to detail in the drafting of policy and guidance documentation. An advantage of close scrutiny and 'drafting by committee' is that end products can be less rushed and so less prone to misinterpretation.

Notwithstanding their differences of approach to decision making, I felt that senior civil servants in the British government were on-message that lawmakers were seriously committed to new technology. They understood that their political bosses wanted public services that saved on costs and empowered citizens to get government services whenever and wherever they wanted.

This does not of course mean that senior staff are any more technically aware (and I was still getting rather tired jokes from some about how younger members of their family knew more about technology than they did. That was never a good defense and it has been a very bad one for many years now). Throughout 30 years of working for government I only once – for a very brief period – worked with a senior technologist. Even this was not typical. As I have said, most British civil servants are generalists, which gives HR more flexibility in their future deployment, while increasing individual prospects for promotion. The tendency for government to buy in specialist help from the private sector also reduces the numbers of internal subject experts. Over the years, government specialist grades were able to build upfavorable terms and conditions. But this also made them more expensive to keep, while their specialist credentials made them more difficult to deploy flexibly.

Information security officers are different. They emerged at a time when government was reducing its pool of specialists, so most of them do not enjoy higher wages and are usually considered 'generalists', that is, they are not qualified specialists but are considered deployable in a broad range of jobs. Typically they will have made their way into security from some routine job, probably not within the field of policy-making (a particular favorite of British career civil servants). Yet they must walk a fine line between understanding the business and its needs, while retaining a good understanding of technology – especially techno-jargon, while being ready to seek common ground between technical and business sides. Actually it is a job like no other. If you can adapt to it, the rewards of being able to reconcile the different outlooks held by technologists and policymakers in government is compensation in itself.

But it can be a slow and sometimes frustrating education. However skillfully a security officer's job description can define his or her responsibilities, senior managers especially can often just see the word 'security' in the title and assume bearers of it will deal with everything in that line. So perhaps the hardest battle of all is to convince senior managers that a security officer is not necessarily also a risk manager and is certainly never (or rarely) a risk taker or risk owner. If a security officer does this too abruptly, it can undermine their true role and professional skills. After all, if a security officer does not 'do' security with that word in their title, what are they for?

Security officers need to be ready with a good and clear answer to that. Though never challenged quite so directly, I felt the most important part of a security officer's role came under the sub-heading of 'information risk manager'. Last year, I felt more certain about this when I took an independent assessment of my experience in security, in order to obtain a new certification. The role of 'security and information risk advisor' was rated the highest of the five target areas I had chosen to certify my skills against.

Establishing that the security risks you identify are not usually yours to manage is difficult enough to carry off. The next difficulty in my experience was the direct request, usually from senior staff, to enable the adoption of a new piece of hardware, normally something out of the box and very often for personal use. I have written here about the pressures to incorporate BYOD in particular. In a bad case, you might not be involved in the consideration process with enough time to ensure security issues were covered. In the worst case (which I did not personally experience) the device might be incorporated into the network with no reference to security at all.

I found the security officer's first notice for this sort of event was often by way of a well-managed change control panel. Ideally, these panels would consider security within the wider context of business change, not as just another issue for security officers to deal with alone. I realized that ensuring a robust and regular change control mechanism got built in to any new service was a great security investment, too. It did mean having to sign up for regular meetings that considered all the minutiae of system changes. But the early warning these provided of security changes, plus the embedding of security within the business change process rewarded the effort of attendance. Sometimes you could delegate attendance at those meetings, too.

The Social Security Officer

Whenever pressures mounted to incorporate a particular device, I felt the correct stance was always to be enabling and cooperative without necessarily conceding to demands. It's also important to keep a sense of proportion when any big issues came up, as there was a natural tendency and pressure for them to swallow up the time you needed to tend other, less distracting projects. This was a challenge to social skills, which I found to be possibly the most important security officer asset of all. Yet they are assets that do not sit well with security technologists. Recently, I spoke to a leading US security thinker who feels strongly that social skills are not properly assessed within popular security certifications. I found that the more technically skilled staff would, consciously or unconsciously, attempt to outdo each other in demonstrating their technical knowledge. This is one disadvantage which I think the UK government did not anticipate when it started buying in the skills of highly competitive and motivated security professionals. The dictum 'too many cooks spoil the broth' is so true in this context I feel it should have been the title of my report on security consultants that I never did write (but would have done if asked).

If you can keep your head when all about you /Are losing theirs and blaming it on you

The quote is from 'If' by Rudyard Kipling. There is much in 'If' to apply to security officers and everyone else but this line in particular is one I have tried to remember at times of security crises. Senior managers can cleave to security officers when things go wrong, and when quick answers are needed because of apparent security failures. So the next most important area to keep up to date on is incident management and reporting. I wrote here recently about preparing for the inevitability of security breaches, especially those involving mobile devices. In practice, it is hard to get across just how pressurized managers can be when an incident has occurred (or seems to have occurred) and the impacts and consequences have not been realized. Quick answers are sought, and there may be an atmosphere approaching panic. This can leads to an overwhelming pressure to limit damage by stopping services or withdrawing the privileges of individual staff.

Some time ago, I recall a security officer colleague who calmly challenged the opinion of a very experienced security consultant that a large system had been hacked. An insistence on establishing fact made our security officer skeptical of the powerful instinct to assume the action of some enemy. It turned out that he was right to do so as on more detailed analysis the glitch was just that. I recall that he impressed senior managers to such an extent that it resulted in a promotion. In fact he had done what senior managers like the most – he had taken away their worries. I should add that security officer was not me, though I did later perform a much reduced reassurance operation based on his example. This one did not lead to a promotion but did cause my then boss to relax – and she remembered it at reporting time, too!

This leads me to the last ingredient of my playbook – the ability to speak two languages: by which I mean to understand what many people would describe as 'geek' language with the ability to reduce it to management speak that busy managers will grasp and not misunderstand. But then to translate these requirements - which may be vague - back into 'geek', so the people who are (often unkindly) perceived as speaking that language have clear instructions about what they need to do to satisfy the non-technologists who lead them. I sometimes wish that authors of detailed articles about security technologies could think about including an 'executive tweet' that would help security officers in this process.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

I hope this has been a useful canter through some things I have learnt about managing expectations, especially from senior managers within large organizations. These tips might not always work – for example, those senior managers who do have a good grasp of technology may second guess us and make us feel very uncomfortable (yes, I've been there too). And then new things will happen that are not in our playbook and we'll need to reprogram ourselves. I would be very interested to hear any tips from readers based upon their own experiences. Getting a consensus on our reactions and helping to get things right might show how security officers are part of the solution to problems, not an additional complication.