Chapter 3 (Part 2) Network Security

1. Chapter 3 (Part 2)Network Security Chapter 3 – Program Security Section 3.4 Targeted Malicious Code Section 3.5 Controls Against Program Threats

2. In this Section • Program Threats • Trapdoors • Salami Attack • Privilege Escalation • Man-in-the-Middle • Covert Channels • Controls Against Program Threats • Modularity • Mutual Suspicion • Hazard Analysis

3. Targeted Malicious Code • So far looked at code written to affect users and machines indiscriminately • Targeted Malicious Code – written for a particular system or application with a particular purpose • Similar to viruses but with the addition of new techniques

4. Trapdoor • Trapdoor – an undocumented entry point to a module. • Inserted for code development • “Hooks” to add additional future enhancements • Can be legitimate or non-legitmate • Software Testing • Unit Testing • Integration Testing • Stubs and Drivers – routines that inject information during testing • Control Stubs – used to invoke debugging code • Accidently left in place • Poor Error Checking

5. Trapdoors • Poorly defined Data • Incomplete Mediation • Undefined Opcodes – instructions that have not been defined for the processor • Trapdoors can be useful • Software audits may request trapdoors to be inserted • Trap doors should always be documented.

6. Causes of Trapdoors • Forgot to remove • Intentionally for Testing • Intentionally left for maintenance • Intentionally left for covert means of access • Trapdoors are not bad. They are not faults until the trapdoor is not shut. • A system is not secure if a trapdoor is present but unknown by others

7. Salami Attack • Named after the way scrap meat is used to form salami • Salami Attack – merges seemingly inconsequential bits of data to yield something important • Classic Salami Attacks • Missing ½ cent • Missing percentage • Taking a bit from a bunch • Charging higher fees • Why do they happen? • Sometimes programmers just except small errors • Code many times it to large to look for salami type errors

8. Rootkits • Rootkit – is a piece of malicious code that goes to great lengths not to be discovered • If discovered tries to reestablish itself • Tries to run itself as “root” on the system (UNIX administrator) • Resides between user and OS • Intercepts commands in order to keep itself hidden • Rootkit Revealer – program written to reveal rootkits • XCP rootkit – used to help prevent copying of music

9. Others • Privilege Escalation-Attack is a means for malicious code to be launched by a user with lower privileges but run with higher privileges • Interface Illusions - spoofing an attack in which all or part of a web page is false • Keystroke Logging – keeps a copy of everything pressed • Man-in-the-Middle Attack- Malicious program exists between tow programs • Timing Attack – identify how fast something happens

10. Covert Channels • Communication information to people/systems that should not have it • Unnoticed communication and accompanies other information • Data written to a drive, sent across a network, placed in a file or printout • Storage Channel – passes information based on presence or non-presence of data • File lock Channel – lock or non-lock of file • Timing Channels – varying speed in system or not using assigned computational time

11. Controls Against Program Threats • Development of Controls • Specify the system • Design the system • Implement the system • Test the system • Review the system at various stages • Document the system • Manage the system • Maintain the systems • Typically it is not one person that does all of these

12. Designing Secure and Usable Systems • You can’t retrofit usable security • Tools aren’t a solution • Min the upper layers • Keep the customers satisfied • Think Locally; act locally

13. Modularity • Small self-contained units • Modularity • Isolates • Hides • Keep it isolated from the effects of other components • Encapsulation – is isolation • Information Hiding – each component hides its precise implementation of some other design decision from others.

14. Modularization • Process of dividing into subtasks • Goal of Modular Units • Single-purpose • Small • Simple • Independent • Advantages of Modularity • Maintenance • Understandability • Reuse • Correctness • Testing

15. Modularity • High Cohesion • All the elements of a component have a logical and functional reason for being there • Low Coupling • The degree with which a component depends on other components in the system • Encapsulation – does not mean complete isolation • Information Hiding – a “black box” approach

16. Mutual Suspicion • Programs are not always trustworthy • Mutual suspicion – each program operates as if other routines in the system were malicious or incorrect • Confinement – program is strictly prohibited in what system resources can be accessed

17. Peer Reviews • Peer review • Hazard analysis • Testing • Good design • Predictions • Static analysis • Configuration management • Analysis of mistakes

18. Types of Peer Review • Review- presented formally • Walk-Through – creator leads and controls the discussion • Inspection – formal detailed analysis • Finding a fault and dealing with it: • By learning how, when, and why errors occur • By taking action to prevent mistakes • By scrutinizing products to find the instances and effects of errors that were missed.

19. Hazard Analysis/Testing • Hazard Analysis – set of systematic techniques to expose potentially hazardous system states. • Hazards and Operability Studies • Failure Modes and effects analysis • Fault tree analysis • Testing • Unit Testing • Integration Testing • Function Testing • Performance Testing • Acceptance Testing • Installation Testing • Regression Testing • Black-box Testing • Clear-box Testing • Independent Testing • Penetration Testing

20. Good Design • Using a philosophy of fault tolerance • Having a consistent policy for handling failures • Capturing the design rationale and history • Using design patterns • Passive fault detection – waiting for a system to fail • Active fault detection – construct a system that reacts to a failure

21. Good Design • Handling Problems • Retrying – restoring the system to previous state and try again • Correcting – resorting the system to previous state and correcting some system characteristic before trying again • Reporting – restoring and reporting but not trying again

22. Configuration Management • Who is making the changes • Corrective change • Adaptive change • Perfective change • Preventive change • Configuration Management – is the process by which we control changes during development and maintenance • Configuration identification • Configuration control and change management • Configuration auditing • Status accounting