240 likes | 358 Views
Insider Access Behavior. Client: The Boeing Company Contact: Mr. Nick Multari Adviser: Dr. Thomas Daniels Group 6 Steven Bromley Jacob Gionet Jon McKee Brandon Reher. Problem Statement.
E N D
Insider Access Behavior Client: The Boeing Company Contact: Mr. Nick Multari Adviser: Dr. Thomas Daniels Group 6 Steven Bromley Jacob Gionet Jon McKee Brandon Reher
Problem Statement • Research and validate existing algorithms, tools, and systems that can detect unauthorized data access and data movement — This approach will be limited to open source and freely available solutions that address the problem • Develop our own toolset and algorithm that will use a user profile to detect unauthorized or abnormal data access and data movement
Functional Requirements • Shall make use of pre-existing technologies • Shall take input from a variety of sources and systems • Shall correlate and filter relevant data • Shall alert when malicious activity is discovered • Shall have a system to provide notifications on alerts • Shall contain an algorithm that decides whether an attack is being committed
Non-functional Requirements • Shall have a low false-positive rate • Shall be inconspicuous to the malicious user • Shall provide alerts in a timely manner • The product shall abide by all licenses of open source software utilized
Technical Constraints & Considerations • The products shall be scalable to a network of up to 1000 machines • The product shall have a low false positive rate • Data shall be obtained from Cyber Defense Competitions • Data shall be obtained from activity scripts
Literature Survey • Insider Threat Prediction Tool: Evaluating the probability of IT misuse • Insider Threat Study: Illicit Cyber Activity in the Banking and Finance Sector • Composite Role-Based Monitoring (CRBM) for Countering Insider Threats
Potential Risks & Mitigation • No simulation data is found • Write activity scripts • Continue search for data • High false positive results • Continue to refine decision algorithm • Miss malicious attacks • Continue to refine filtering algorithm
Project Milestones and Schedule • Research options for threat detection • Choice made on what methods will be used in product • Equipment has proper systems • All the systems of a LAMP architecture are installed on the machines allocated to the group • Data is obtained • Group had large amounts of data that contain both outside and inside malicious attacks
Functional Decomposition • Log Analyzer • Gather Logs from the different systems installed on the network, give them a standard format, and store them in a central repository • Network Analyzer • Profiling Algorithm • Profile log information, look for anomalies in user profile activity, and raise alerts when malicious activity is detected
User Interface • Installation Interface • Trusted administrators will have an initial interface in which they can input trusted users and the access control lists • Runtime Interface • Normal users will have no interface to the system • Alert Interface • Trusted administrators will view alert details in the form of an e-mail message sent to the trusted administrator list
Hardware Platform (cont.) • Dell machines were profiled for market survey due to high market presence
Software Platform Operating Systems System Libraries • Apache • MySQL • PHP Third-Party Software • Ettercap • Snort • Splunk • NetBSD • Version 2.6.0 • Red Hat Enterprise Linux (RHEL) • Version 6.0
Test Plan - Environment • Test Environment • Located on an ISEAGE-provided computers • Consists of small scale network that is designed to represent a scaled down version of a generic enterprise network • Focus is on the intranet traffic
Test Plan - Design Scenario 1 Scenario 2 • Network Traffic • Procedure • Create controlled traffic on the network • Compare the captured packets to the traffic created to determine if entire traffic sequences were captured. • Log Gathering • Procedure • Manually start the log gathering system to gather a known set of logs from predefined locations. • Compare the logs retrieved with the logs in the source location to determine if all logs were successfully collected.
Test Plan – Design (cont.) Scenario 3 Scenario 5 • Entire System • Procedure • Script various activity types, including malicious and legitimate activity • Monitor generated alerts to verify that malicious and suspicious activities are the only events reported • Measure the response time from activity to alert report • Alert System • Procedure • Input the alert flag / trigger to the system to create an alert • Monitor the reporting mechanism to verify that the alert is created successfully
Current Project Status • Machine Setup • Basic Installation Complete • Non-interference with ISU network • Data Detection Method • Location of Data Sources • Literature & Market Survey • Profiling Algorithm
Plan for Next Semester • Setup and Configuration of Toolset • Develop Profiling Algorithm • Transform abstract algorithm to concrete program • Testing and Modifications • Extensive testing of components to ensure proper results are obtained. • Compile Report of Successes and Failures