Home » Process
Category Archives: Process
Cultural Differences
I have had the honour of working with the US Secret Service in the past, a role that involved moments of tension, good humour, a fair bit of coffee drinking, and some very intelligent conversations.
One related to the difference of approach to Protection work based on the cultural background of the host country. For a Presidential Visit, the USSS work with the local security teams to agree how the President will be protected – this is a balance between the expectations of the USSS and the local knowledge of the hosts. For example what is ideal in the US may be problematic for the host country and a better alternative suggested.
Most of this is a pragmatic conversation between experts, however culturally there may be fundamental differences that lead to certain responses.
- In some countries, if a VIP is attacked they will be moved away from the threat.
- In other countries, if the VIP is attacked they will defended at the scene.
Culturally, running away may not be seen as acceptable and to expect it may therefore meet with resistance. The planned response may not be followed.
The existence of these cultural differences also applies within companies, especially multinationals or companies formed by mergers, where different teams have different cultures that may in the event of an emergency clash with the preplanned corporate responses. In the worst cases, you can find that not only are reacting to an attacker but also your own side.
Running exercises to identify the issues is important, as is clearly defining expectations and roles in handling an incident.
Bad things will happen
How you react to them, and whether you manage them or they control you is a matter of planning, but no one likes to plan for a risk becoming an issue.
Risk Registers are built and Controls are put in place to control the risks. A control, however, only reduces a risk rather than eliminates it completely. There is still a possibility of the events in the risk actually occurring. It is a common failing to believe that identifying a risk, and associating a Control with it makes the risk disappear.
Planning for a Controlled Risk actually happening often feels like a worthless activity, and so there is little effort or enthusiasm in performing it. There is also a view that says “We don’t know what will happen (if we did we’d have stopped if happening), therefore we can’t plan for it.” This is largely true, but a general structure and roles in addressing an event can be established.
The aim of an incident response plan is to reduce the opportunity for chaos, enabling a business to recover as quickly as possible and to reduce the losses.
What is in the plan?
- Pre-agreed Roles and Responsibilities.
- How an the Incident Team is triggered
- Who owns the Incident.
- The support they can call on: Technical and Security experts, Media Relations, Property and Transport.
- How the Team will Communicate, both between the members of the team and with other stakeholders.
- What records they will keep.
- What authority they have
- What limitations will they have on funding and resources.
Doesn’t this sound similar to a Business Continuity and Recovery Plan?
Risk Registers
Something like this always appears on a Security Risk Register from the IT department:
“High Risk: The USB ports on the Servers are not locked down.”
And the security team in the IT Department sit and shake their heads and wonder why The Business doesn’t seem to understand how important IT security is. They’ve said it there: High Risk. Probably in an Excel Spreadsheet cell with a bright red background.
This isn’t a Risk to the Business. Something like “A journalist could obtain our list of sensitive clients, which would be extremely embarrassing and lead to loss of our client base and thus income” is a Business Risk. There is an understandable Threat (A Journalist) a target (List of Sensitive Clients), there is an outcome that threat succeeding they can understand (Loss of Clients leading to a loss of business), and you can understand how keen and capable that threat source is (can Journalist hack? can they persuade someone to give them information? How interested are they likely to be?) and that gives you a measure of how probable it is that that Risk will be realised and become an issue.
Now you have a realistic risk the Business can understand, and importantly might want to do something about. Then you can look at what you could do to Control that Risk. In this case, that could be such things as “Check employee backgrounds when we recruit them to jobs with access to the List of Sensitive Clients”, “Educate Users not to plug strange USB devices into computers”, may be even: “Lock the USB ports”.
Then “the USB ports aren’t locked” becomes a Risk Control that is not currently effective, meaning that the Business Risk of “A journalist obtaining our Sensitive Client List” isn’t being controlled to the full expectation of the business. There are still other good controls, such as employees knowing not to plug stuff in, but there is a chink in the armour. Then you can now tell a story that the business will understand, and they might well want to act on it. That one Control may actually be used to mitigate a whole range of Business Risks, in which case it not being effective would be a larger concern.
Of course, you could just fill the USB Ports with a two part epoxy…
Patch and Be Damned
Why do you test manufacturer patches before releasing them? So you don’t disrupt the Business when you apply them.
What if the exposure to a Business Disrupting Security Event is greater because you haven’t patched?
What is the balance of the two risks?
Security Patches, issued by a large software company are a nicely package guide to where Security Vulnerabilities can be found. These are rapidly reverse engineered by the malware and criminal hacking community – and they work very quickly since their window of opportunity is small, but their rewards are great. This is why critical Vulnerabilities, such as Heartbleed, are announced after the major affected systems have patches available or implemented.
So, should you test Security Patches before deployment? Why not just deploy patches before an attacker uses their vulnerabilities against you?
But know you are doing it. Have an approved Patching Policy, and have a routine for it – a Patching Procedure: Backup or Snapshot systems beforehand (one of the big benefits of virtualisation) then if there is an issue you can quickly revert and start to investigate the cause of the issues.
After all, you have a business continuity plan to handle minor disruptions don’t you? Better to have a test of that than a real use of your Security Incident Plan.
(And you do have a Security Incident Plan don’t you?)
