Why your staff ignore security policies and what to do about it.
Dale Carnegie’s 1936 bestselling self-help book How To Win Friends And Influence People is one of those titles that sits unloved and unread on most people’s bookshelves. But dust off its cover and crack open its spine, and you’ll find lessons and anecdotes that are relevant to the challenges associated with shaping people’s behaviour when it comes to cyber security.
In one chapter, Carnegie tells the story of George B. Johnson, from Oklahoma, who worked for a local engineering company. Johnson’s role required him to ensure that other employees abide by the organisation’s health and safety policies. Among other things, he was responsible for making sure other employees wore their hard hats when working on the factory floor.
His strategy was as follows: if he spotted someone not following the company’s policy, he would approach them, admonish them, quote the regulation at them, and insist on compliance. And it worked — albeit briefly. The employee would put on their hard hat, and as soon as Johnson left the room, they would just as quickly remove it. So he tried something different: empathy. Rather than addressing them from a position of authority, Johnson spoke to his colleagues almost as though he was their friend, and expressed a genuine interest in their comfort. He wanted to know if the hats were uncomfortable to wear, and that’s why they didn’t wear them when on the job.
Instead of simply reciting the rules as chapter-and-verse, he merely mentioned it was in the best interest of the employee to wear their helmets, because they were designed to prevent workplace injuries.
This shift in approach bore fruit, and workers felt more inclined to comply with the rules. Moreover, Johnson observed that employees were less resentful of management.
The parallels between cyber security and George B. Johnson’s battle to ensure health-and-safety compliance are immediately obvious. Our jobs require us to adequately address the security risks that threaten the organisations we work for. To be successful at this, it’s important to ensure that everyone appreciates the value of security — not just engineers, developers, security specialists, and other related roles.
This isn’t easy. On one hand, failing to implement security controls can result in an organisation facing significant losses. However, badly-implemented security mechanisms can be worse: either by obstructing employee productivity or by fostering a culture where security is resented.
To ensure widespread adoption of secure behaviour, security policy and control implementations not only have to accommodate the needs of those that use them, but they also must be economically attractive to the organisation. To realise this, there are three factors we need to consider: motivation, design, and culture.
Your company has decided to adopt Cloud. Or maybe it was among the ones that relied on virtualised environments before it was even a thing? In either case, cloud security has to be managed. How do you go about that?
Before checking out vendor marketing materials in search of the perfect technology solution, let’s step back and think of it from a governance perspective. In an enterprise like yours, there are a number of business functions and departments with various level of autonomy. Do you trust them to manage business process-specific risk or choose to relieve them from this burden by setting security control objectives and standards centrally? Or maybe something in-between?
Managing security centrally allows you to uniformly project your security strategy and guiding policy across all departments. This is especially useful when aiming to achieve alignment across business functions. It helps when your customers, products or services are similar across the company, but even if not, centralised governance and clear accountability may reduce duplication of work through streamlining the processes and cost-effective use of people and technology (if organised in a central pool).
If one of the departments is struggling financially or is less profitable, the centralised approach ensures that overall risk is still managed appropriately and security is not neglected. This point is especially important when considering a security incident (e.g. due to misconfigured access permissions) that may affect the whole company.
Responding to incidents in general may be simplified not only from the reporting perspective, but also by making sure due process is followed with appropriate oversight.
There are, of course, some drawbacks. In the effort to come up with a uniform policy, you may end up in a situation where it loses its appeal. It’s now perceived as too high-level and out of touch with real business unit needs. The buy-in from the business stakeholders, therefore, might be challenging to achieve.
Let’s explore the alternative; the decentralised model.
This approach is best applied when your company’s departments have different customers, varied needs and business models. This situation naturally calls for more granular security requirements preferably set at the business unit level.
In this scenario, every department is empowered to develop their own set of policies and controls. These policies should be aligned with the specific business need relevant to that team. This allows for local adjustments and increased levels of autonomy. For example, upstream and downstream operations of an oil company have vastly different needs due to the nature of activities they are involved in. Drilling and extracting raw materials from the ground is not the same as operating a petrol station, which can feel more like a retail business rather than one dominated by industrial control systems.
Another example might be a company that grew through a series of mergers and acquisitions where acquired companies retained a level of individuality and operate as an enterprise under the umbrella of a parent corporation.
With this degree of decentralisation, resource allocation is no longer managed centrally and, combined with increased buy-in, allows for greater ownership of the security programme.
This model naturally has limitations. These have been highlighted when identifying the benefits of the centralised approach: potential duplication of effort, inconsistent policy framework, challenges while responding to the enterprise-wide incident, etc. But is there a way to combine the best of both worlds? Let’s explore what a hybrid model might look like.
The middle ground can be achieved through establishing a governance body setting goals and objectives for the company overall, and allowing departments to choose the ways to achieve these targets. What are the examples of such centrally defined security outcomes? Maintaining compliance with relevant laws and regulations is an obvious one but this point is more subtle.
The aim here is to make sure security is supporting the business objectives and strategy. Every department in the hybrid model in turn decides how their security efforts contribute to the overall risk reduction and better security posture.
This means setting a baseline of security controls and communicating it to all business units and then gradually rolling out training, updating policies and setting risk, assurance and audit processes to match. While developing this baseline, however, input from various departments should be considered, as it is essential to ensure adoption.
When an overall control framework is developed, departments are asked to come up with a specific set of controls that meet their business requirements and take distinctive business unit characteristics into account. This should be followed up by gap assessment, understanding potential inconsistencies with the baseline framework.
In the context of the Cloud, decentralised and hybrid models might allow different business units to choose different cloud providers based on individual needs and cost-benefit analysis. They can go further and focus on different solution types such as SaaS over IaaS.
As mentioned above, business units are free to decide on implementation methods of security controls providing they align with the overall policy. Compliance monitoring responsibilities, however, are best shared. Business units can manage the implemented controls but link in with the central function for reporting to agree consistent metrics and remove potential bias. This approach is similar to the Three Lines of Defence employed in many organisations to effectively manage risk. This model suggests that departments themselves own and manage risk in the first instance with security and audit and assurance functions forming second and third lines of defence respectively.
We’ve looked at three different governance models and discussed their pros and cons in relation to Cloud. Depending on the organisation the choice can be fairly obvious. It might be emerging naturally from the way the company is running its operations. All you need to do is fit in the organisational culture and adopt the approach to cloud governance accordingly.
The point of this article, however, is to encourage you to consider security in the business context. Don’t just select a governance model based on what “sounds good” or what you’ve done in the past. Instead, analyse the company, talk to people, see what works and be ready to adjust the course of action.
If the governance structure chosen is wrong or, worse still, undefined, this can stifle the business instead of enabling it. And believe me, that’s the last thing you want to do.
Be prepared to listen: the decision to choose one of the above models doesn’t have to be final. It can be adjusted as part of the continuous improvement and feedback cycle. It always, however, has to be aligned with business needs.
|Centralised model||Decentralised model||Hybrid model|
|A single function responsible for all aspects of a Cloud security: people, process, technology, governance, operations, etc.||Strategic direction is set centrally, while all other capabilities are left up to existing teams to define.||Strategy, policy, governance and vendors are managed by the Cloud security team; other capabilities remain outside the Cloud security initiative.|
When building a house you would not consider starting the planning, and certainly not the build itself, without the guidance of an architect. Throughout this process you would use a number of experts such as plumbers, electricians and carpenters. If each individual expert was given a blank piece of paper to design and implement their aspect of the property with no collaboration with the other specialists and no architectural blueprint, then it’s likely the house would be difficult and costly to maintain, look unattractive and not be easy to live in. It’s highly probable that the installation of such aspects would not be in time with each other, therefore causing problems at a later stage when, for example, the plastering has been completed before the wiring is complete.
This analogy can be applied to security architecture, with many companies implementing different systems at different times with little consideration of how other experts will implement their ideas, often without realising they are doing it. This, like the house build, will impact on the overarching effectiveness of the security strategy and will in turn impact employees, clients and the success of the company.
For both of the above, an understanding of the baseline requirements, how these may change in the future and overall framework is essential for a successful project. Over time, building regulations and practices have evolved to help the house building process and we see the same in the security domain; with industry standards being developed and shared to help overcome some of these challenges.
The approach I use when helping clients with their security architecture is outlined below.
I begin by understanding the business, gathering requirements and analysing risks. Defining current and target states leads to assessing the gaps between them and developing the roadmap that aims to close these gaps.
I prefer to start the security architecture development cycle from the top by defining security strategy and outlining how lower levels of the architecture support it, linking them to business objectives. But this approach is adjusted based on the specific needs.
This is one of these blog posts with no content. I just really wanted to share some pics from one of the coolest cities I had a privilege to live and work in for the past few months.
Cyber security is a manpower constrained market – therefore the opportunities for AI automation are vast. Frequently, AI is used to make certain defensive aspects of cyber security more wide reaching and effective: combating spam and detecting malware are prime examples. On the opposite side there are many incentives to use AI when attempting to attack vulnerable systems belonging to others. These incentives could include the speed of attack, low costs and difficulties attracting skilled staff in an already constrained environment.
Current research in the public domain is limited to white hat hackers employing machine learning to identify vulnerabilities and suggest fixes. At the speed AI is developing, however, it won’t be long before we see attackers using these capabilities on mass scale, if they don’t already.
How do we know for sure? The fact is, it is quite hard to attribute a botnet or a phishing campaign to AI rather than a human. Industry practitioners, however, believe that we will see an AI-powered cyber-attack within a year: 62% of surveyed Black Hat conference participants seem to be convinced in such a possibility.
Many believe that AI is already being deployed for malicious purposes by highly motivated and sophisticated attackers. It’s not at all surprising given the fact that AI systems make an adversary’s job much easier. Why? Resource efficiency point aside, they introduce psychological distance between an attacker and their victim. Indeed, many offensive techniques traditionally involved engaging with others and being present, which in turn limited attacker’s anonymity. AI increases the anonymity and distance. Autonomous weapons is the case in point; attackers are no longer required to pull the trigger and observe the impact of their actions.
It doesn’t have to be about human life either. Let’s explore some of the less severe applications of AI for malicious purposes: cybercrime.
Social engineering remains one of the most common attack vectors. How often is malware introduced in systems when someone just clicks on an innocent-looking link?
The fact is, in order to entice the victim to click on that link, quite a bit of effort is required. Historically it’s been labour-intensive to craft a believable phishing email. Days and sometimes weeks of research and the right opportunity were required to successfully carry out such an attack. Things are changing with the advent of AI in cyber.
Analysing large data sets helps attackers prioritise their victims based on online behaviour and estimated wealth. Predictive models can go further and determine the willingness to pay the ransom based on historical data and even adjust the size of pay-out to maximise the chances and therefore revenue for cyber criminals.
Imagine all the data available in the public domain as well as previously leaked secrets through various data breaches are now combined for the ultimate victim profiling in a matter of seconds with no human effort.
When the victim is selected, AI can be used to create and tailor emails and sites that would be most likely clicked on based on crunched data. Trust is built by engaging people in longer dialogues over extensive periods of time on social media which require no human effort – chatbots are now capable of maintaining such interaction and even impersonate the real contacts by mimicking their writing style.
Machine learning used for victim identification and reconnaissance greatly reduces attacker’s resource investments. Indeed, there is even no need to speak the same language anymore! This inevitably leads to an increase in scale and frequency of highly targeted spear phishing attacks.
Sophistication of such attacks can also go up. Exceeding human capabilities of deception, AI can mimic voice thanks to rapid development in speech synthesis. These systems can create realistic voice recordings based on existing data and elevate social engineering to the next level through impersonation. This, combined with other techniques discussed above, paints a rather grim picture.
So what do we do?
Let’s outline some potential defence strategies that we should be thinking about already.
Firstly and rather obviously, increasing the use of AI for cyber defence is not such a bad option. A combination of supervised and unsupervised learning approaches is already being employed to predict new threats and malware based on existing patterns.
Behaviour analytics is another avenue to explore. Machine learning techniques can be used to monitor system and human activity to detect potential malicious deviations.
Importantly though, when using AI for defence, we should assume that attackers anticipate it. We must also keep track of AI development and its application in cyber to be able to credibly predict malicious applications.
In order to achieve this, a collaboration between industry practitioners, academic researchers and policymakers is essential. Legislators must account for potential use of AI and refresh some of the definitions of ‘hacking’. Researchers should carefully consider malicious application of their work. Patching and vulnerability management programs should be given due attention in the corporate world.
Finally, awareness should be raised among users on preventing social engineering attacks, discouraging password re-use and advocating for two-factor-authentication where possible.
The Malicious Use of Artificial Intelligence: Forecasting, Prevention, and Mitigation 2018
Cummings, M. L. 2004. “Creating Moral Buffers in Weapon Control Interface Design.” IEEE Technology and Society Magazine (Fall 2004), 29–30.
Seymour, J. and Tully, P. 2016. “Weaponizing data science for social engineering: Automated E2E spear phishing on Twitter,” Black Hat conference
Allen, G. and Chan, T. 2017. “Artificial Intelligence and National Security,” Harvard Kennedy School Belfer Center for Science and International Affairs,
Yampolskiy, R. 2017. “AI Is the Future of Cybersecurity, for Better and for Worse,” Harvard Business Review, May 8, 2017.
Let’s talk about applying the SABSA framework to design an architecture that would solve a specific business problem. In this blog post I’ll be using a fictitious example of a public sector entity aiming to roll-out an accommodation booking service for tourists visiting the country.
To ensure that security meets the needs of the business we’re going to go through the layers of the SABSA architecture from top to bottom.
Start by reading your company’s business strategy, goals and values, have a look at the annual report. Getting the business level attributes from these documents should be straightforward. There’s no need to invent anything new – business stakeholders have already defined what’s important to them.
Every single word in these documents has been reviewed and changed potentially hundreds of times. Therefore, there’s usually a good level of buy-in on the vision. Simply use the same language for your business level attributes.
After analysing the strategy of my fictitious public sector client I’m going to settle for the following attributes: Stable, Respected, Trusted, Reputable, Sustainable, Competitive. Detailed definitions for these attributes are agreed with the business stakeholders.
Next step is to link these to the broader objectives for technology. Your CIO or CTO might be able to assist with these. In my example, the Technology department has already done the hard job of translating high-level business requirements into a set of IT objectives. Your task is just distill these into attributes:
Now it’s up to you to define security attributes based on the Technology and Infrastructure attributes above. The examples might be attributes like Available, Confidential, Access-Controlled and so on.
The next step would be to highlight or define relationships between attributes on each level:
These attributes show how security supports the business and allows for two-way tracebility of requirements. It can be used for risk management, assurance and architecture projects.
Back to our case study. Let’s consider a specific example of developing a hotel booking application for a public sector client we’ve started out with. To simplify the scenario, we will limit the application functionality requirements to the following list:
|P001||Register Accommodation||Enable the registration of temporary accommodations available|
|P002||Update Availability||Enable accommodation managers to update availability status|
|P003||Search Availability||Allow international travellers to search and identify available accommodation|
|P004||Book Accommodation||Allow international travellers to book accommodation|
|P005||Link to other departments||Allow international travellers to link to other departments and agencies such as the immigration or security services (re-direct)|
And here is how the process map would look like:
There are a number of stakeholders involved within the government serving international travellers’ requests. Tourists can access Immigration Services to get information on visa requirements and Security Services for safety advice. The application itself is owned by the Ministry of Tourism which acts as the “face” of this interaction and provides access to Tourist Board approved options. External accommodation (e.g. hotel chains) register and update their offers on the government’s website.
The infrastructure is outsourced to an external cloud service provider and there are mobile applications available, but these details are irrelevant for the current abstraction level.
From the Trust Modelling perspective, the relationship will look like this:
Subdomain policy is derived from, and compliant with, super domain but has specialised local interpretation authorised by super domain authority. The government bodies act as Policy Authorities (PA) owning the overall risk of the interaction.
At this stage we might want to re-visit some of the attributes we defined previously to potentially narrow them down to only the ones applicable to the process flows in scope. We will focus on making sure the transactions are trusted:
Let’s overlay applicable attributes over process flows to understand requirements for security:
Now it’s time to go down a level and step into more detailed Designer’s View. Remember requirement “P004 – Book Accommodation” I’ve mentioned above? Below is the information flow for this transaction. In most cases, someone else would’ve drawn these for you.
With security attributes applied (the direction of orange arrows define the expectation of a particular attribute being met):
These are the exact attributes we identified as relevant for this transaction on the business process map above. It’s ok if you uncover additional security attributes at this stage. If that’s the case, feel free to add them retrospectively to your business process map at the Conceptual Architecture level.
After the exercise above is completed for each interaction, it’s time to go down to the Physical Architecture level and define specific security services for each attribute for every transaction:
At the Component Architecture level, it’s important to define solution-specific mechanisms, components and activities for each security service above. Here is a simplified example for confidentiality and integrity protection for data at rest and in-transit:
|Service||Physical mechanism||Component brands, tools, products or technical standards||Service Management activities required to manage the solution through-life|
|Message confidentiality protection||Message encryption||IPSec VPN||Key management, Configuration Management, Change management|
|Stored data confidentiality protection||Data encryption||AES 256 Disk Encryption||Key management, Configuration Management, Change management|
|Message integrity protection||Checksum||SHA 256 Hash||Key management, Configuration Management, Change management|
|Stored data integrity protection||Checksum||SHA 256 Hash||Key management, Configuration Management, Change management|
As you can see, every specific security mechanism and component is now directly and traceable linked to business requirements. And that’s one of the ways you demonstrate the value of security using the SABSA framework.
Governments across Europe recognised that with increased interconnectiveness a cyber incident can affect multiple entities spanning across a number of countries. Moreover, impact and frequency of cyber attacks is at all-time high with recent examples including:
- 2017 WannaCry ransomware attack
- 2016 attacks on US water utilities
- 2015 attack on Ukraine’s electricity network
In order to manage cyber risk, the European Union introduced the Network and Information Systems (NIS) Directive which requires all Member States to protect their critical national infrastructure by implementing cyber security legislation.
Each Member State is required to set their own rules on financial penalties and must take the necessary measures to ensure that they are implemented. For example, in the UK fines, can be up to £17 million.
And yes, in case you are wondering, the UK government has confirmed that the Directive will apply irrespective of Brexit (the NIS Regulations come into effect before the UK leaves the EU).
Who does the NIS Directive apply to?
The law applies to:
- Operators of Essential Services that are established in the EU
- Digital Service Providers that offer services to persons within the EU
The sectors affected by the NIS Directive are:
- Health (hospitals, private clinics)
- Energy (gas, oil, electricity)
- Transport (rail, road, maritime, air)
- Digital infrastructure and service providers (e.g. DNS service providers)
- Financial Services (only in certain Member States e.g. Germany)
NIS Directive objectives
In the UK the NIS Regulations will be implemented in the form of outcome-focused principles rather than prescriptive rules.
National Cyber Security Centre (NCSC) is the UK single point of contact for the legislation. They published top level objectives with underlying security principles.
- A1. Governance
- A2. Risk management
- A3. Asset management
- A4. Supply chain
- B1. Service protection policies and processes
- B2. Identity and access control
- B3. Data security
- B4. System security
- B5. Resilient networks and systems
- B6. Staff awareness
- C1. Security monitoring
- C2. Proactive security event discovery
- D1. Response and recovery planning
- D2. Lessons learned
Table view of principles and related guidance is also available on the NCSC website.
Cyber Assessment Framework
The implementation of the NIS Directive can only be successful if Competent Authorities can adequately assess the cyber security of organisations is scope. To assist with this, NCSC developed the Cyber Assessment Framework (CAF).
The Framework is based on the 14 outcomes-based principles of the NIS Regulations outlined above. Adherence to each principle is determined based on how well associated outcomes are met. See below for an example:
Each outcome is assessed based upon Indicators of Good Practice (IGPs), which are statements that can either be true or false for a particular organisation.
If your organisation is in the scope of the NIS Directive, it is useful to conduct an initial self-assessment using the CAF described above as an starting point of reference. Remember, formal self-assessment will be required by your Competent Authority, so it is better not to delay this crucial step.
Establishing an early dialogue with the Competent Authority is essential as this will not only help you establish the scope of the assessment (critical assets), but also allow you to receive additional guidance from them.
Initial self-assessment will most probably highlight some gaps. It is important to outline a plan to address these gaps and share it with your Competent Authority. Make sure you keep incident response in mind at all times. The process has to be well-defined to allow you report NIS-specific incidents to your Competent Authority within 72 hours.
Remediate the findings in the agreed time frames and monitor on-going compliance and potential changes in requirements, maintaining the dialogue with the Competent Authority.