Data and Information

A key component in research is data, which when processed and interpreted becomes information.  It therefore very important that the data (information) is protected at all stages during its lifecycle.

The Basics

A most common model designed to guide policies and practices for Information Security in an organisation is the AIC (availability, integrity and confidentiality) triad. What this means is that we use the triad to see if there are any risks to the data/information at each stage in the dataflow.
The next section covers a very simple dataflow that involves an exchange of information between entities, its processing, storage and subsequent transformation into a report.

The Case

A research study would like to interview patients (includes medical history and personal details) and prepare a research report. The interviews are conducted using encrypted voice recorders and the interviews are uploaded to the cloud for automated transcription. The converted text is then downloaded to the researcher’s machine and a research report is prepared. Sounds simple enough? Yes, but!

What could possibly go wrong?

There are several gaps where a breach could take place. Let’s identify some of them and see what controls (if any) can be implemented.
The encrypted voice recorders aren’t configured correctly, or the user has forgotten to turn the encryption function on. Maybe the user writes the password down and stores it along with the voice recording device. Oops! Not too bad, but what if the voice recording device is lost along with the password? Another point to watch out for; if the device uses an outmoded algorithm, in which case the encryption can be easily subverted and the recording/s accessed.

Brace yourself: we are heading into the Unknown Land of Terror and Tedium. Yes, the domain of the Auditor!

Seriously, though, it isn’t as scary, or as boring, as that. Having carried out audits for two different security standards (ISO/IEC 27001 and PCI DSS), I have visited that Land, and am able to unveil its mysteries to you. I’ve also been audited, so have seen both sides of the process.

First, dismiss any thought of auditing being uniform across all standards. Auditors are trained very differently depending upon what they are auditing against. For example, payment card audits are very technical, while 27001 audits can be carried out by non-technical (but trained and experienced) people.

It’s auditing, so there must be a list…

Having said that, there are significant similarities between the audits I have been involved in. As this is about audit, there needs to be a list:

• You have to audit against something, a fixed point of comparison. This is usually a standard. You can audit against policy, too.
• Audits tend to have predefined possible outcomes: e.g. pass or fail.
• Audits also produce “non-conformities”, or “findings” relating to parts of the document which you are auditing against.
• Audits look for evidence of compliance; positives, not negatives. A good auditor is looking for reasons to give their client a pass.
• Hard evidence is key to the whole thing. There is a saying: if it’s worth doing, it’s worth documenting. But proof doesn’t have to be documentation. Some standards can be satisfied by everyone demonstrably doing the same thing.
• Auditors usually test part of the environment to be audited, not the whole thing. So even if you pass an audit, that’s not bullet-proof.
• There are two different types of audit: internal and external.
• External auditors are from a company specialising in audit, which is usually “accredited” to prove that it provides a good quality of audit.
• Internal auditors are often internal to your company, but can be from another company. They do not have to be accredited, as their findings are private to the company being audited.
• Internal audits usually look at part of the standard to be audited against, not the whole thing. More of a spot check than a full review.
• If you are an external auditor from an accredited auditing company, and the company you audit passes the audit, it can say that it is “certified”. Not “accredited”!
• You can be asked to audit part of an environment, not the whole thing. This can get really messy if it isn’t clearly agreed and documented.
• Auditors tend to think of EVERYTHING as a process.

To sum up

I hope that this has given you a little peek inside the world of auditing, and that it wasn’t as tedious or unsettling as you expected!

There are a number of special terms which are bandied about in the world of information security. Today let’s look at “governance”. Even in the rest of the business world, the term is a little slippery. People use it in conjunction with “strategy” a lot. Let’s start by taking a look at it by itself; what can we see?

Governance is in the eye of the beholder

I like to think of this as being the proverbial “elephant described by people who have only seen a part of it” situation. People who are in hands-on operational roles see one facet. People in top management see another, and external organisations yet another. It could be a source of edicts; it could be a lever to move the earth (cf Galileo), or it could even be a magic Harry Potter mirror in which one can see what one cares about the most.

What about when it’s not there?

OK, so governance looks different to everyone, depending on what your role is. Next, we can ask ourselves what is it for? Or more interestingly, what happens if you don’t have governance?

One thing you don’t get is a clear idea of where you are going, and how close you are to getting there. Another thing you don’t get is any idea of what is and isn’t allowed. You have a good chance of going round in circles.

The purpose and definition of governance

The main purpose of governance, then, is to provide direction and purpose to an organisation.

As to what it is, I like the definition used by the World Bank:

“[the process] by which authority is conferred on rulers, by which they make the rules, and by which those rules are enforced and modified.”

This makes a bit more sense at last. We can apply this definition very cleanly to the arena of information security, where we consider the rules to be relating to information risk management, and the “rulers” to be the organisation’s top management, e.g. the senior management team, or the board of directors. It incorporates the idea of delegation, of creation, and of enforcement and monitoring.

Do we already address governance in information security?

If you look at the text of ISO/IEC 27001, you will find that it is essentially a blueprint for information security governance. It also goes into a bit of depth on management, which for my money is the way in which governance is enacted.

Previously

We looked at what information privacy is and how information sharing affects us all. We also had a brief look at what Privacy Impact Assessment (PIA)  is and its contribution to the organisation in terms of safeguarding reputation and reducing costs.

This blog piece covers the basic aspects of a PIA.

Privacy Risk

Privacy risk is the risk of harm arising through an intrusion of privacy. Privacy harm can be caused through the use or misuse of personal information. This harm can be quantifiable or tangible; an individual could lose their job. It could also be less tangible; damage to personal relationships. Going a bit further, what might not be a great harm to an individual a cumulative loss of data could be a huge damage to society.
Some of the ways that this can arise by personal information:

• being inaccurate, insufficient or out of date,
• excessive or irrelevant
• kept for too long
• disclosed to inappropriate individuals;
• used in ways that are unexpected or unacceptable to the person it is about; or
• not kept securely

The outcome of a PIA should be the minimisation of privacy risk. This involves the understanding of what constitutes privacy and privacy risk. There is no one size fits all as one can imagine. Data collection for visa issuance is far different than that for an admission process even though personal information is collected in both situations. Thus privacy risk involves an understanding of the relationship between the organisation and the individual.

Something to think about .

Does your organisation need to be aware of obligations under the Human Rights Act?
If so, use a PIA to ensure that any actions that interfere with the right ot private life are necessary a proportionate.

That’s all for this blog! In the next blog, I intend to cover the benefits of a PIA and whose responsibility it is of conducting a PIA

Further reading:
https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf

There is a type of security which is nothing but smoke and mirrors; a ceremony of actions which has no actual effect but that of making people feel better.

This can be a good thing, or a bad one.

What do we mean by “risk appetite”?

An organisation uses security measures to meet its obligations to other parties (including the government). However, the organisation also needs to meet its “risk appetite”. The exec and the board, or the senior management team, take the strategic priorities and plans of the organisation into account, then work out how much information risk is just short of “too much”. That level is its risk appetite.

Clear enough? OK, now remember that the organisation is composed of individual people. They each have their own individual risk appetite; their own idea of what is an acceptable level of risk.

Some people will think that the organisation is too draconian, with policies which are overkill. Others will feel their concerns on information risk are being ignored, and believe that the organisation is dicing with death.

When might ceremonial security be worthwhile?

For people in the latter category, you can implement something which makes them feel better about risk, but doesn’t actually make any actual difference. By doing this, you may benefit both the individual (they get to sleep at night) and the organisation (they get a better performing staff member and they are not over-egging the pudding).

When might ceremonial security be damaging?

What if you implement risk management activities which don’t have a beneficial effect, even though they are actually expected to? Let’s pick an example. Imagine that  you implement mandatory virus scanning on your computers- but you take no action if a virus is detected, and no-one ever looks at the results of the scans. That’s a dangerous situation. You have something which looks like a very good idea, but is exactly useless. It may even have a negative effect on security, as you may assume you are safe from viruses, and let down your guard.

In summary…

What’s the take-home lesson from this? Maybe it’s that there are different ways to see risk, but no “single right answer”. Those who look for the simple, easy way out are doomed to believe that they have found it.

What is a control? If you have spent more than five minutes talking to me or my team, we will probably have spoken of “controls”, and probably risk (but let’s stick to controls for this post).

Definition of a control

A control is a change you make to part (or all) of an organisation to reduce its exposure to information risk. For example, you may decide to put sensitive documents into a shredder when they are not needed any longer, rather than putting them in the standard paper recycling. Or you could encrypt files on shared storage, rather than storing them in clear text.

So a policy is NOT a control, but in fact describes a control. For example, you may create a policy stating that all passwords must be at least ten characters long.

Categorising controls

3D render of files on bookshelves

There is a tendency amongst all people who look at security controls to try to fit them into categories. A common set is:

• Physical
• People
• Technical
• Process/organisational

This helps people to understand what thing a control is changing. A physical control, for example, will be a physical change (e.g. putting a lock on a door, or shredding paper). A technical control could be applying security patches to systems within X days. A process control could be performing a security review when a change is planned to a system. A people control could be doing background checks on people who are to be granted access to sensitive information.

Other attributes

Questions multicolour

There are many other ways of categorising a security control. These can be used as appropriate. Examples include:

• Main purpose: detective, reactive, preventative
• Intended effect on risk: reduction of impact, reduction of likelihood, or both
• Which role(s) it applies to: which are responsible, accountable, consulted and informed
• Which part(s) of the organisation it applies to
• How long it is intended to be in effect for
• What sanctions will apply if it is not applied
• What risk(s) it is intended to affect
• What business process(es) relate to it

Hello, this is my obligatory introduction post! My name is Ian Carter and I’m the newest member of ISG, having been working in the team for just under two months.

My role within the team is to look after the monitoring aspect of Information Security. This involves trying to detect and respond to threats against UCL assets.

Some specific tasks that I have are:

• Using monitoring technology to detect and respond to attacks
• Providing metrics to our stakeholders
• Developing and maintaining the monitoring systems that we use

The role also involves a lot of liaison with other people, both within Information Services, and more widely.

Monitoring Tools

We use a number of tools to collect and analyse data, but a brief description of the main ones is below.

Intrusion Detection/Prevention Systems (IDS/IPS)

The most common analogy for an IDS is that of a burglar alarm. Sensors are places at sensitive areas, such as points of entry, and if triggered an alarm is generated that needs a human to take some action.

An IPS takes this a step further by removing the human decision making and automatically taken action if an alarm is generated, such as blocking a malicious user. Obviously you need to be very sure this is not likely to be a false alarm!

Technically these systems work very much like antivirus products, they compare observed behaviour to a number of rules. This means to be effective the rules have to be constantly updated, as attacks are evolving all the time. A part of my role is ensuring the rules are effective and relevant, and don’t generate lots of false alarms.

Security Incident and Event Management (SIEM)

A SIEM is a little like a spiders web. It takes information from lots of systems, like the IDS and servers, which are like the strands in a web.  All this information is correlated together and analysed. Some of the information may be suspicious, which is like the web being tugged, and if enough activity is generated an alarm occurs and the analyst, or spider, pounces. However, there is an awful lot of background noise, much like the wind blowing on a web, that needs to be filtered out so only the important information remains.

The major benefit of this system is the way alarms are prioritised so we can respond to the really important things more quickly. They also provide lots of reports that are useful for generating metrics.

I hope this is useful summary of some of the tools we use, I’ll delve into them a little deeper in future posts.

 

“Phishing is a fraudulent attempt, usually made through email, to steal your personal information”. – PhishTank.

Phishing is unfortunately something that we have to learn to live with, it’s not going to go away any time soon. The best way to protect ourselves against phishing is to learn to identify it.

Things to look out for

1. A sense of:
   1. Urgency – makes you feel like you have to do something quickly, so you don’t take the time to wonder if the email is suspicious.
   2. Fear – for example, if you don’t click on the link, your account will be deleted, or you will be fined.
   3. Promise of reward – lottery win notifications, or “I am the widow of a rich person” type of email.
   4. Guilt or sympathy – “I am dying of…” type of email.
   5. So if an email makes you feel: guilty, panicky, afraid, or greedy, stop and ask yourself why. It’s probably a phishing email.
2. ‘To‘ and ‘From‘ address – these can be trivially forged and show false information. Often the ‘To’ address isn’t even your email address, a legitimate email would be addressed to your actual email address.
3. Web link – check to see if the link is in the UCL domain (ucl.ac.uk), it could look like a legitimate UCL URL but check by hovering over it as it could be going somewhere else entirely.
4. Asking you to respond with your username and/or password – no legitimate email will ask you to do this.
5. Unexpected attachment – some phishing emails come with attachments that when opened will compromise your computer.
6. Headers and signatures – these can be forged, phishing emails often use them to appear more legitimate.

The consequences of responding to a phishing email (or opening an attachment in a phishing email) are that an attacker can steal your information and/or take control of your machine.

If you are ever unsure whether an email is a phishing email or not, before you click or respond, just ask us – isg@ucl.ac.uk.

In my next blog post I will be talking about test phishing campaigns.

Hello, my name is Daniela Cooper and I am the longest standing member in ISG, 13 years this year to be exact. If you’ve been at UCL a while and had to contact ISG it’s likely that you’ve spoken to me. It’s less likely going forward as our team has since grown quite a lot.

My current role concentrates on the awareness side of information security, I am responsible for the following:

• The ISG website (including the web presence for the Security Working Group, the Information Risk Management Group, the Information Risk Governance Group)
• Promotional materials
• Information security presentations
• Phishing campaigns (more on those in a future blog post)
• Information security awareness campaigns
• The Moodle Information Security Awareness course (https://moodle.ucl.ac.uk/course/view.php?id=35689)

In my next blog post I will talk about phishing.