Security Week 10 Lecture 1

Why do we need security? Identify and authenticate people wanting to use the system Prevent unauthorised persons from accessing the system Stealing information Doing malicious damage Prevent authorised persons from Doing things they ought not Seeing data they ought not

Security in perspective Read the preface from Schneier’s book –it is on the web “Security is a chain; it's only as secure as the weakest link.” "Security is a process, not a product." “If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology.”

Or Computer system security is NOT Network security and Network Security is not Cryptography

And Like Reliability and Performance Security starts in design and continues for the life of the system

Common misconceptions – The Economist - October 26 th 2002 Security can be fixed with technology Security can be left to the specialists Security is about virus outbreaks and malicious hackers Security is very boring This article is up on the web.

Access WAN Communications LAN Physical Data Where is the risk?

Another quote Mathematics (cryptography) are impeccable Computers are vincible Networks are lousy People are abysmal

Three key elements Prevention Detection Reaction

Security risks are within Most books concentrate on network security, but most DIS are of little interest to people outside Most security breaches are from within the organisation and by relatively technically illiterate people (one survey suggests 70% of attacks are from inside) They are people who want something they ought not have – like your medical records, your pay details, your exam marks – perhaps next month’s DIS exam!

Security is in the hands of: System architect Analysts & Programmers System administrator Database administrator Network manager Risk manager According 70% of security defects are due to flaws In software design.

Risk assessment Identify the risk before determining the solution We used to secure the perimeter, now there is no door to lock

Security starts with policies Hardware and software implement policies (the police and the law courts would be of little use without legislation) The policy statement will: State that security is important to the organisation Define the principles underlying the organisation’s security Define what constitutes acceptable use Give notice that security is monitored State what the procedure is when security is breached The aim is to make security everyone’s business

Publicity is important A policy is of little use if all staff do not know about it In some organisations new staff are required to read and sign the security policy Reminders are necessary It needs to be kept up to date It helps to have the odd public execution

Policies, Standards & Procedures Policy Password access is required to all key systems Standard defines how the policy is to be achieved Passwords are to be changed every 3 months Passwords must not be repeats of previous passwords Passwords will have a minimum of 6 characters Etc Procedure implements the standard A temporary password is allocated by personnel, as part of the user account creation process The temporary password has a currency of 1 week and must be changed by the user within that period etc

Access level Staff are grouped according to the rights and responsibilities they have on the system For example the policy on access to the HR system may be: Staff can view their own records Staff have access to the telephone and office/location list for all staff Staff can change own home contact and next of kin details Other staff details may only be changed by HR staff Managers have access to the records of staff reporting to them

This gives a matrix of rights Staff can see full list of staff but showing limited details Managers can see all details of staff they are responsible for Staff can change some details of own record HR can change all details Managers can change no details

We have three access levels Staff Managers HR people But we also need to know: The ID of the person accessing the system The staff that report to a manager The department a person is in

How do we implement this? Within the application because we know the functions of the system Within the database, users can be restricted Not allowed to use DBA functions May see some tables but not update them May be restricted to see or update a “view” of a table

What is a view? A view can be a subset of the records and/or a subset of the attributes of those records Example –Create view STAFF_LIST as –Select STAFF_RECORD where STAFF_ID is equal to USER_ID This view might be appropriate for staff looking at their own records

Identification & authentication Identification – “Who are you” Authentication – “Prove it” Its aim is to –Let authorised persons in –Keep unauthorised persons out –Keep a record of what happens

Authentication is based on Something you know – password Something you are – biometrics Something you have – card or token And often two of these –Your Mastercard & –PIN number

Authentication of the user The whole mechanism is dependent on a reliable authentication of the person accessing the system In most systems this is done by password But passwords can be easily misused KPMG auditor quoted as saying most passwords can be broken within 30 seconds Canadian police reckon the key to a person’s password is within 2 metres of his or her PC But we are asked to remember so many passwords and then change them every three months

People often give their password to others Usually because they need that person to do their job System should allow a person to give another a proxy to act on their behalf, but where they can use their own password People with high access levels have to be very careful

People who leave are sometimes a security risk A client list may be handy in their next job Restrict people to what they need to know Restrict physical access to servers, tape drives, back-up tapes etc Limit the quantity of data that can be listed – in pages of printout Restrict access to DBMS tools

There are other means of authentication Keyboards can accept swiped ID cards Tokens that generate random numbers in synch with the operating system Modems generate password or require call back Physical access via electronic key Thumb, voice or retina scan

Identity management systems Software that sits in front of an organisation’s applications Identifies and authenticates Determines users privileges One point of control, so that things don’t get missed Can be maintained by managers not technical staff.