Computer Security set of slides 10

1. Computer Securityset of slides 10 Dr Alexei Vernitski

2. System log files • All kinds of events which might interest the administrator later are kept in log files • Typically they are in the directory /var/logs (in Linux) • They store all occurrences of successful and unsuccessful logins, web server statistics, database statistics, etc. • Similar logs (called Event logs) exist in Windows

3. Event logs (in Windows) • Application log • For example, a database program may record a file error in the application log. • Security log • The security log records events such as valid and invalid logon attempts, as well as events related to resource use, such as the creating, opening, or deleting of files. • System log • For example, if a driver fails to load during startup, an event is recorded in the system log. Windows XP predetermines the events that are logged by system components.

4. System log files • The administrator needs to specify which events are recorded in the logs. • The administrator can view the logs • Logs are either human-readable in Linux, or special commands are provided such as faillog • Event Viewer program in Windows • The administrator might need special software to analyse and interpet the logs.

5. Intrusion detection systems • Intrusion detection systems are designed to: • detect an attack while it is in progress (maybe allowing it to be stopped before if succeeds) • detect an attack after it has happened (allowing a SysAdmin to repair the damage caused by the attack after it has happened)

6. Intrusion detection systems - examples • AIDE (Advanced Intrusion Detection Environment) • it can be used to verify the integrity of the files. It has several message digest algorithms (see below) that are used to check the integrity of the file. All of the usual file attributes can also be checked for inconsistencies. • AIDE is included in Linux installations

7. Intrusion detection systems - examples • Tripwire is a large IDS employing a number of approaches • Checking file integrity • Checking system logs • ‘security event management’ and ‘real-time incident detection’: detecting suspicious events and responding to them immediately

8. Sample security policy • part 1: physical and physically mobile systems

9. Physical security • Is physical security adequate? (e.g. for many companies all visitors/employees at a site require identification). Some rooms containing valuable data/resources might need additional security measures.

10. Disposal • Ensure that systems and media are securely disposed when finished with.

11. Ownership • Ownership of: • Equipment • Code • Data • Ensure that users are under a contract such that equipment and data/software created are owned by the company and are not “stolen”, and ensure that users understand this (e.g. a contractor might write code for one company and then reuse it for another company - this is probably a form of “theft”). • Have a special policy with regard to mobile systems such as laptops (what data can be stored on them, how the systems and the data on them is secured etc.)

12. Sample security policy • part 2: user access systems

13. Choosing secure passwords • Check when users create/change passwords that they are not obviously insecure (e.g. do not allow dictionary words, require passwords to contain a range of character types, do not allow passwords related to login name, disallow passwords that are car registration numbers) • Regularly run password cracking programs on your users encrypted passwords looking for possible weak passwords.

14. Managing passwords • Make users change passwords regularly (this stops password cracking programs from having enough time to break intercepted encrypted passwords)

15. Non-password security • For higher security use techniques additional to or instead of password security (e.g. biometric, public key based systems)

16. Access rights • Only give users access to systems/data/information that they really need for their role • this requires a database of systems that users can connect to and when controls should be updated (e.g. a shared system password may need to be changed as soon as an employee that knew the password leaves)

17. Sample security policy • part 3: user training

18. Security training • Train all computer users in basic security which could include: • ways to create secure passwords • never writing down system security information (e.g. passwords) • never reveal system/computer information to anyone unless you are sure of their identity and even then only give appropriate information • never install unauthorised software on computers • never share data from sources outside the company until it has been scanned (e.g. never get a document from a USB stick from non-company source) • never connect machines directly to the Internet (many companies ban their users from connecting to the Internet from their laptops or work machines installed in their homes - instead the users have to connect to the company’s secure “virtual private network” VPN)

19. Personal use of computers • restrict use of computer resources for personal use (this may ban users from using email for personal use)

20. Secure configuration • require users to have their virus scanners on all of the time (and personal firewalls on)

21. Encryption • require users to send sensitive data over encrypted media

22. Communication • inform users how they can communicate with system administrators

23. Further training • make user computer users get (and read) regular security policy updates and attend regular training

24. Sample security policy • part 4: secure configurations

25. Updating software • All computers must have up to date software installed - this requires some automated updating system. However, it has to be done carefully - e.g. updating some server components can overwrite configuration files in such a way that they may run some “insecure” default configuration.

26. Restrictions on client machines • “Lock down” client machines e.g. many companies give employees machines that have minimal external access (e.g. PCs without: USB data ports, CD-ROM, floppy drive) and configured so the user cannot install any software or configure any system settings. The user is only given the access and utilities that they really need.

27. Server precautions • Configure server machines to only run necessary services. • For servers connected to the Internet - increase the “security hardening” and assume they may be compromised and treat them accordingly (i.e. keep them separate from internal networks/computers)

28. Sample security policy • part 5: backup

29. Backup • securely back up data in a timely manner (e.g. daily is probably good enough for most office related tasks, but duplicates of all transactions might be needed for banking data) • store backups in a different (and secure) physical location • test that the backup system is actually working and storing the necessary data • some servers may require backup systems ready to be deployed when needed.

30. Sample security policy • part 6: use preventative security tools

31. Scanning the system • Regularly scan computer systems on the network to test that they are only running necessary (and authorised) services (external security scanner) • Regularly scan computer systems with “local security analysers” that check that computers are properly secured (e.g. running automatic software update tools and have reasonable configurations)

32. Scanning the data • Scan all incoming data: • remove software or data that might be infected with trojans or viruses. • block unsolicited communication e.g. email spam

33. Scanning for permissions • filesystems will be scanned checking that files have appropriate permissions (e.g. you might like to check that your home directories are not “world” readable)

34. Sample security policy • part 7: the system administrators

35. Employing administrators • Employ “expert” staff as system administrators (and their managers) and train system administrators to a high standard • expert system knowledge is only gained by years of personal experience • System administrators regularly check security web-sites for the latest known system exploits. They should regularly read security emails from the distributor of each operating system (and major application) that they are supporting.

36. Sample security policy • part 8: review and test policy

37. Security policy review • Regularly check through the site security policy • this may be a simple “paper test” of policy as part of a general “quality assurance” review

38. Employing outsider experts • a more rigorous (and literally “intrusive”) technique might involve a “tiger team” analysis • A tiger team is defined as ‘a team of undomesticated and uninhibited technical specialists, selected for their experience, energy, and imagination, and assigned to track down relentlessly every possible source of failure’

39. Risk analysis • Run a risk analysis to ascertain what parts of the policy need changing