eby Experimental Platform For Model

Experimental Platform for Model-Based Design of Embedded Systems : 

Experimental Platform for Model-Based Design of Embedded Systems Matt Eby, Jan Werner, Janos Mathe, Gabor Karsai, Sandeep Neema, Janos Sztipanovits, Yuan Xue Institute for Software Integrated Systems, Vanderbilt University ﴀ ﴀ April 27, 2006 System is a test bed for the Modeling and Analysis of Complex Systems (MACS) group at Vanderbilt University The three tank system was chosen as an archetypical component controlled by SCADA system Three tank systems are common in chemical processing systems Tanks 1 & 2 regulate fluid levels in Tank 3 while Tank 3 supplies fluid to some process downstream We use this system to demonstrate and test the capabilities of security measures introduced via Model-Based Design Other Potential Attacks Taxonomy Control System Security Model Plant Simulation Simulink Models Real-Time Workshop Mathworks xPC Target DSML Code Generator Embedded System Model Secure System Model The experimental platform facilitates “Hardware”-in-the-Loop testing of controllers. High fidelity plant simulations behave just as the actual physical environment would. Controllers can run on various operating systems with different security designs. Code for controllers is generated based on security models for the embedded system Picture The experimental platform is configured for specific control problems such as a Three Tank System controlled by a SCADA system. We then test a variety of attacks against the system This allows us to exercise the code produced from the security models for: Performance overhead Strength of security for specific attacks Comparison between different operating systems Configuration of Experimental Platform for Three Tank Testing Tank 1 Tank 3 Tank 2 Under normal conditions Tank 3 will fill up then stay within a defined range (in this case 0.45 m to 0.55 m). The tanks will overflow if fluid height exceeds 0.8 m. For the tests conducted on a Three Tank Controller we are running Gentoo Linux (kernel 2.4.32) with GRsecurity extensions. GRsecurity adds 3.9% (33 kB) to the kernel footprint Performance overhead is 3.5% for non-executable memory protection GRsecurity extensions allow fine grained control over system resources I/O registers Memory Protection Inter-process Communication FSM Diagram of Controller With I/O register protection only the tank control process has permission to write to I/O channels Model-Based approach can map desired security properties to underlying platform services such as POSIX capabilities (e.g. CAP_SYS_RAWIO) Denial of Service attack can increase execution time of tank control process Operation under normal conditions Worst case execution time = 12712 μs Mean execution time = 3123 μs Denial of Service attack on network data access component Worst case execution time = 52600 μs Mean execution time = 23200 μs DoS attacks cannot be easily prevented without support of platform services such as packet filtering.