Proposal defense presentation
•
10 likes•10,530 views
Presentation that I used for proposal defense
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Proposal defense presentation
Similar to Proposal defense presentation (20)
More from Ruchika Mehresh
Recently uploaded
Recently uploaded (20)
Proposal defense presentation
- 1. PROACTIVE SCHEMES FOR MISSION ASSURANCE IN CRITICAL SYSTEMS Ruchika Mehresh Ph.D. Dissertation Proposal Defense Department of Computer Science and Engineering University at Buffalo, The State University of New York December 20, 2011 Advisor : Dr. Shambhu Upadhyaya Committee Members : Dr. H. Raghav Rao Dr. Murat Demirbas
- 2. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 3. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 6. INTRODUCTION Prevention Detection Recovery
- 10. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Deception as a tool Component 1 Component 2 Component 3 Threat Model Solution Evaluation
- 12. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 13. PROBLEM FORMULATION 1. System type : Mission critical 2. Last wall of defense : secure recovery phase for mission survivability 3. Mission Survivability : Satisfy timeliness property 4. Indefinite missions : time-independent security strength 5. Focus : on event’s impact, not cause 6. Attack model : basis for solution design 7. Tamper-proof : ‘Who watches the watcher ?’ 8. Effective Evaluation 9. Integrity over availability
- 15. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 20. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 21. SOLUTION DESIGN Component 1: Surreptitious intrusion detection by keeping the IDS tamper-proof Component 2: Making the integrity signature invisible and accessible to the attacker Component 3: Deception-based proactive recovery scheme, and multi-phase evaluation framework
- 23. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 26. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 33. SIMPLE ARCHITECTURE Intrusion detector or a crucial user space service Lightweight process monitor Direction of Monitoring Process i runs on core i , and 1≤i≤K, where K is the total number of cores on the processor Numbers from 1-K indicate the K cores of the host’s processor 2 3 4 5 6 1 K K-1
- 40. EVALUATION – TAMPER RESISTANCE Figure: Alerts generated for killing process monitors in sequential order without delay, under light system load Figure: Alerts generated for killing process monitors in sequential order without delay, under heavy system load
- 42. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 44. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 46. THREAT MODEL
- 47. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 49. Coordinator Replica 1 Replica 2 Replica 3 Replica n Workload Workload Workload Workload Workload Replica 3 R R R R Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature Need at least a duplex system H C H C H C H C Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature Periodic checkpoint Hardware Signature
- 51. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 56. RESULTS
- 57. RESULTS
- 59. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 61. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 63. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
- 64. DISSERTATION OUTLINE Chapters Topic s Chapter 1 Introduction Chapter 2 Background Chapter 3 Problem Formulation Chapter 4 Surreptitious intrusion detection by keeping the IDS tamper-proof (For both centralized and decentralized environment) Chapter 5 Making the integrity signature invisible and accessible to the attacker (For both centralized and decentralized environment) Chapter 6 Deception-based secure proactive scheme (For both centralized and decentralized environment) Chapter 7 Evaluation Chapter 8 Conclusion
- 65. PRESENTATION OUTLINE Introduction Motivation Problem Formulation Background Solution Remaining Work Dissertation Outline Conclusion Threat Model Solution Evaluation Deception as a tool Component 1 “ Who watches the watcher” Component 2 “ Hiding detection” Component 3 “ Deception-based recovery”
Editor's Notes
- - Hacking community as it is, has been gathering momentum with dedicated forums that not only provide powerful, ready-to-use tools to script kiddies, but also an excellent communication medium for the professionals -Example: Electricity in hospitals
- Mission survivability: doesn’t differentiate between benign or malign cause
- Mode 1: A short running mission with a definite timeline Usually for such missions, final phase is the most crucial. If we hold off the aggressive behavior of an attacker for long enough, while still maintaining the mission integrity, we can assure mission survivability. Mode 2: A long running mission with an unbounded timeline In long running missions, it may not be possible to hold off the attacker forever. This is especially true for mission critical systems with infinite timelines (like, web based businesses). A full system recovery will be essential. However, as we will see later in Section 4, recovery can be attacked if we recover the system to the same vulnerable state that was exploited before. Thus, the need is to identify the precise vulnerability that resulted in the exploit and close it during the recovery. Such analysis takes time and hence a smart solution will buy the defender more time, without triggering a change in attacker’s rational behavior. If not, the defender can risk the attacker executing his contingency plans
- Multi-stage delivery of malware Botnet’s stealthy command and control execution model Stealth features of Stuxnet sniffs for a specific configuration and inert itself if it does not find it. limited spread (one to three) Erases itself on a specific date on which it erases itself. Spread in industry “ Stuxnet is the new face of 21st-century warfare: invisible, anonymous, and devastating ”
- Recovery based: Assumes system is compromised as soon as it goes online
- mapping and vulnerability analysis of US critical infrastructure to plan for future attacks Rapid adoption of technology like smart grids more vulnerable due to automation and remote access people working on the smart grid are not concerned about security. “ The emergence of Stuxnet points to an overriding need for critical infrastructure companies to acknowledge the changes in the cyber threat landscape and focus attention not only on denial-of-service attacks, but also on more sophisticated threats, like stealthy infiltration from state-sponsored actors or cyber-extortionists. As our research has shown, the critical infrastructure sector has been slow to adjust to this realization.” cyber-security experts concerned about the surveillance of U.S. power grid by other nation states. A classified 2008 Defense Science Board Report highlights the cyber vulnerabilities in the US electric grid. Potential opponents have been observed to engage in cyber-reconnaissance of US critical infrastructure electrical utilities to plan for attack. A statistic reported by this survey shows a stable and high number of perceived nation-sate network attacks against domestic critical infrastructure. Cyber security experts concerned about international surveillance Potential opponents have been observed to engage in cyber-reconnaissance of US critical infrastructure electrical utilities to plan for attack
- Knapp and Boulton and make a strong case for why cyber warfare is not just a military domain issue now. They study trends that demonstrate the transformation of information warfare from primarily a military-domain related issue to an industry-related issue. Coporate spionage Nation states avoiding direct confrotation Terrorism, extortion and hacktivism Baskerville discusses the expansion of information warfare to electronic business domain. He discusses the asymmetric warfare theory and how it relates to information warfare. Attackers are not restricted by time to develop exploit as much as defenders are. Another asymmetry is attacker’s advantage of stealth. Therefore, a defense system needs to be agile and adaptive in order to balance out this asymmetry.
- Component 1: Surreptitious intrusion detection by keeping the IDS tamper-proof Component 2: Making the integrity signature invisible and accessible to the attacker Component 3: deception-based proactive recovery scheme, and multi-phase evaluation framework
- Antivirus virus (retrovirus) Attacks/disables or infects the antivirus Software assets become defenseless Attacks bypass AV protection Called “argument-switch” attack, exploits driver hooks the AV programs use Send benign code and later swap with malicious payload E.g., remove McAfee and install malware Easier to do in a multi-thread, multi-core setup
- AMD SimNow is installed on Ubuntu which is the host operating system. Inside AMD SimNow, we run a guest operating system, i.e., FreeBSD. All experiments run on this guest operating system. This system is configured to use emulated hardware of AMD Awesim 800Mhz 8-core processor with 1024 MB RAM. We use kernel level filters to implement process monitoring. This is because inter-process communication support provided by UNIX-like systems (like pipes or sockets) does not suffice for our framework. Inter-process communication delivers messages only between two live processes. However, we require that a communication (alert) be initiated when a process is terminated. For this purpose, we use an event delivery/notification subsystem called Kqueue, which falls under the FreeBSD family of system calls. Under this setup, a process monitor interested in receiving alerts/notifications about another process creates a new kernel event queue (kqueue) and submits the process identifier of the monitored process. Specified events (kevent) when generated by the monitored process are added to the kqueue of the process monitor. Kevent in our implementation is the termination of the monitored process. Process monitors can then retrieve this kevent from their kqueues at any time. A process monitor can monitor multiple processes in parallel using POSIX threads.
- The initial setup time is defined as the time taken for the kqueue subsystem to get loaded before an attacker tries to subvert the process monitors. This is the only major time delay this system has been observed to incur. Initial setup time increases linearly with increasing degree of incidence. With 8 process monitors in a circulant digraph topology, the worst case initial setup delay of 0.3ms is obtained with a maximum degree of incidence.
- We experimented with different circulant digraph topologies with varying number of process monitors and degree of incidence, as shown in the table. We experiment with the worst case scenario where the attacker already knows the correct order of the nodes in this topology. We assume that he also identifies the windows of vulnerability and uses them to his advantage (again, the worst case). In the figure, the number of alerts generated shows the sensitivity of this framework toward a crash attack executed using SIGKILL, under light system load.
- Composability : The functionalities of the potential sub-modules can be composed to provide the functionalities of their parent module. Sufficiency : The functionalities of the potential sub-modules collectively describe the entire set of functionalities of their parent module.
- For our analysis, checkpoint interval is assumed to be 1 hour. Fig. 2 presents the execution times for the four Scimark workloads on a logarithmic scale. It can be seen that the execution time overhead increases only a little when the system transitions from Case 1 to Case 2 (i.e., employing the proposed scheme as a preventive measure). For instance, an application that runs for 13.6 hours for Case 1 will incur an execution time overhead of only 13.49 minutes in moving to Case 2. However, the execution time overhead increases somewhat rapidly when the system transitions from Case 2 to Case 3. The increase in execution overhead will be substantial only if there are too many faults/attacks present, which is not very common. Fig. 3 shows the percentage increase in execution times of various workloads when the system transitions from a lower case to a higher one. It is assumed that these executions do not have any interactions (inputs/outputs) with the external environment. The percentage increase in execution time is only around 1.6% for all the workloads when system transitions from Case 1 to Case 2. The overhead for a transition from Case 1 to Case 3 (with mean time to failure, M =10 hours) is around 9%. These percentages indicate acceptable overheads in most fault tolerant systems.
- Need for extending the framework to a decentralized environment: As with all centralized architectures, the framework that we developed has a single point of failure. Its trusted computing base is limited only to the coordinator. This can be advantageous because it is easier to ensure whether a single system is running tamper-free or not. However, since it will be connected to compromised systems during a mission cycle, we cannot assume that it will stay secure forever. Thus, we would like to go beyond our extreme dependence on this single entity. While moving towards decentralization, we will conduct a detailed investigation about the various candidate topologies, the candidate voting procedures, the limited trusted computing base, etc. A user will submit his job randomly to multiple replicas in this decentralized framework. Similarly, it will obtain information from randomly selected multiple replicas and will perform a majority voting. Following are the prime areas that we will investigate for building the solution: Choosing the topology The topology can range from anything completely decentralized, to cluster formation, to even having a trusted computing base with multiple coordinators. We add a replica to the blacklist till either the mission is complete or the suspected replica has been completely profiled and believed to be uncompromised. This is because if we keep adding replicas to the blacklist aggressively and predictably, we may risk availability of the service and it can lead to a denial of service attack. Thus, we predict that there will be some centralized components in the new framework because it will not be very efficient to have each replica profile every other replica. Choosing the secure, distributed voting algorithm We plan to leverage features from [49] and other secure voting algorithms to reach a distributed consensus about the integrity status of replicas. Since the system requirements here are very different from any of the work done before, we will have to modify the presented algorithms in order to suit our purpose. Reputation-based mechanisms We will investigate the possibility of using reputation mechanisms as a substitute for blacklisting. Possible use of Nexus In an ideal environment, COTS paradigm is most useful since stronger system could be built without depending on any dedicated or specially designed components. However, the proposed solution requires some minimal intervention to harvest the built-in redundant logics in a chip. So, as an alternative solution, we propose software approaches such as the Nexus platform [50] to achieve the same effect of trusted monitoring using the built-in hardware.
- Status