Figure 1 – Visual analysis of Nessus vulnerability log in JMP 9
Edward Swing, VSTI, a SAS Company, Ed.Swing@vsticorp.com [PRIMARY Contact]
Kevin Boone, VSTI, a SAS Company, Kevin.Boone@vsticorp.com
Brian Espinola, SAS, Brian.Espinola@sas.com
Clinton Totten, VSTI, a SAS Company, Clinton.Totten@vsticorp.com
SAS Institute's Base SAS 9.2 was utilized to transform and merge the log files from the provided formats to individual SAS datasets. This resulted in each log type (firewall, intrusion detection, etc.) yielding one SAS dataset. Wireshark 1.4.6 was also used as part of the transformation process for the packet capture logs.
The log datasets were visually analyzed via a combination of SAS software: Enterprise Data Guide 4.3 and JMP Pro 9. The SAS datasets were loaded into these programs as needed to perform various analytic processes. The most common tools used were graphs of distribution and interactive charts.
Approximately 70 hours were required for the transformation process, most of which was time to engineer the transformation processes. Programming required about 20 of those hours, and program execution accounted for roughly 2 of the hours. The actual analysis required 30 additional hours.
MC 2.1 Events of Interest: Using the new situation awareness display(s), what noteworthy events took place for the time period covered in the firewall, IDS and syslog logs? Which events are of concern from a security standpoint? Limit your answer to no more than five noteworthy events. For each event, at least one of the submitted screen shots must be relevant in your explanation of the event.
With consideration to the fact that the supplied logs covered events that occurred in the past, the first visual analysis (discussed here) was approached from a forensic perspective as opposed to an alerting perspective. The analyst tried to determine what happened, when and why, and how could the event(s) affect the network.
The first step of the analysis process was to examine the Nessus vulnerability scan log for any issues. Using the interactive distribution graphing capabilities of JMP 9, it was quickly determined that five of the company’s workstations had high-risk security holes (Figure 1). Each of the five included multiple issues, such as the ability for a user to elevate privileges.
Figure 1 – Visual analysis of Nessus vulnerability log in JMP 9
This visualization tool also quickly revealed that as many as 236 of the company’s workstations were not powered on during the scan, and therefore could not be truly analyzed for problems. With consideration to the issues identified on the five workstations that were successfully scanned, it is likely that significant vulnerabilities also exist on the others.
The intrusion detection system (IDS) logs were also viewed with the interactive graphing capability of JMP 9. The same five workstations identified in the vulnerability log produced the most alerts in the IDS system (Figure 2).
Figure 2 – Vulnerable host IP addresses also cause most IDS alerts
While the IDS log was opened in JMP 9, the analyst double-clicked the bar that represented denial-of-service attacks. A tabular view of the data appeared (Figure 3) and illustrated that the company’s public facing web server, IP 172.20.1.5, was victim of a denial-of-service attack from external sources on April 13.
Figure 3 – Denial-of-service attacks against web server
Examination of the firewall log in Enterprise Guide 4.3 and JMP 9 showed that the denial of service attack and five vulnerable workstations combined accounted for most of the network traffic, with a result of poor service to the employees and customers of the company. Any email or web requests would be affected by the extra network traffic.
The firewall log was also examined for traffic heading to or from the shipping and routing database server, based on odd entries that were noted in the log. Enterprise Guide 4.3 was used to examine the tabular data from the firewall log (Figure 4) and characterize the data. Only two SQL queries were recorded during the three day period, on April 15. SQL queries are expected to the server, and indicative of someone viewing, editing, or creating a scheduled shipment. The log also indicates numerous instances of “Microsoft DS” (directory services) traffic coming in to port 445 in rapid succession, which is the trigger for this particular analytic. A web search indicated that the particular service and port are often used to automatically scan and infect computers that are on the same subnet in order to build a botnet for an eventual denial-of-service attack. The same web search indicated the port should be blocked at the firewall to prevent such attacks.
Figure 4 – Traffic to/from shipping and routing database server
Each of these findings is of concern from a network security perspective, especially the vulnerable workstations, denial of service attack, and Microsoft-ds service activity. All of these issues should be addressed by the company’s IT department, and the company’s leadership should be briefed on the issues and possible ramifications.
MC 2.2 Timeliness: For each event submitted in MC 2.1, how early in the course of the event would your display(s) enable a CNO team member to recognize that the event was noteworthy? For each event, specify the earliest moment of recognition as a timestamp and provide a screen shot at the earliest moment of recognition. Explain how the CNO team member had enough information to determine that the event warranted attention.
As noted in response to MC2.1, the analyst approached the review from a forensic perspective. He did not receive alerts about potential threats as they were occurring, nor soon after they happened. However, all of the tools and processes utilized in the analytic workflow can be scripted by SAS Enterprise Guide 4.3 into a cyber-security program.
The problems that the analyst looked for can be captured into a rule set that the program would check against to determine if a record, or series of records, was a noteworthy event from a security perspective. Much like the virus definition databases in common anti-virus software, the rule set can be populated with the current knowledge of the computer security industry, and continue to grow as new threats appear.
The program would offer the ability for near real-time analysis for threats, and a combined dashboard/alerting system. As fast as the log files from the firewall, intrusion detection system, and vulnerability scanner can be transformed into SAS datasets, the program would have them available for analysis. Once analyzed, any records that indicate a threat could be flagged, an alert would be sent to network security personnel, and a dashboard of network threats would be updated. A robust rule set would mean events could be flagged at varying levels of concern, e.g. “suspicious”, “probable threat”, “definite problem”. As more information arrived from the logs, the threat level of existing events would be updated. The dashboard could utilize the interactive charts of JMP Pro 9 for more detailed investigations when a threat arose.
Such a program was not created in response to this challenge. SAS Enterprise Guide allows for scripting and scheduling of the analytic workflow, however (Figure 5). That is the basis for an alerting and dashboard system that offers near real-time monitoring of network traffic for security concerns.
Figure 5 – Scheduled workflow in Enterprise Guide
MC 2.3 Recommendations: What are the implications of the events discovered in MC 2.1? What report should the CNO give to the CEO and/or what actions should the CNO take to improve security?
All Freight Corporation has a highly vulnerable network that results from poor security practices. Major issues include risky ports opened on the firewall and bad security policies implemented on workstations. These problems have led to denial-of-service attacks that result in awful network performance and potentially a loss of customers. With consideration to recent events in Vastopolis, it is possible that someone utilized the company’s trucks to carry out terrorist activity. However, hacking incidents that may be related to that event are difficult to trace given the volume of log reports that relate to denial-of-service attacks and botnet issues.
The company should inform authorities of the denial-of-service attack, inclusion of company servers on a botnet, and the single SQL request to the shipping database server for investigation. The network team should brief leadership of the issues, and immediately institute stricter security policies.