Chapter 28 : Application-Specific Dashboards Introduction
A better representation of application attacks can be usually be achieved by building custom dashboards instead of open source and commercial event log management tools. The possibilities are greater, but possibly require more effort. Application-specific attack dashboards are currently an aspect still being developed, and additional ideas and code samples are likely to be available in the near future. Further ideas for information security consoles and dashboards can be found at SecViz128.
Organizations may have their own application dashboards, and some of the ideas below could be used to extend those.
Description AppSensor WS
The project’s reference code implementation demonstrates how simply information from the Event Analysis Engine can be rendered in a web page. See Part IV : Demonstration Implementations - Chapter 20 : Web Services (AppSensor WS).
Detection Point, Attack and Response Data Displayed by AppSensor WS
[JM – screen capture????]
Streaming Comet
Example application-specific dashboards were demonstrated at OWASP AppSec EU 2011. The demos broadcast example event and attack data to a server which used the Comet model to push real-time updates to an active web page console129.
An Example AppSensor Dashboard for an Ecommerce Website
In this the detection points are shown relative to the application’s main functional areas are listed across the top with an indicator “light” above each position.
An Example Detection Point Indicators on Website Functionality Map
These light up red on attack detection and then fade through orange to yellow and white again over a suitable time period, so they are not completely ephemeral.
Illumination of Detection Point Indicators
Trend monitoring detection points are showing a separate area at the bottom right of this model dashboard. As data is dynamically updated, the rows change color to indicate refreshes and indicators of trend direction.
System Trend Detection Points
Highlighting of Changes to System Trend Detection Points
A panel is updated in real time as events occur. In this example where detection points also exist in public areas, there are a larger number of events. The corresponding detection point indicators are illuminated as events appear.
Detection Points Event Log Display
Automated real-time responses are displayed in another panel.
Response Event Log Display
This is of course all completely custom to the application and the individual organization’s view of threats.
AppSensor coverage
Coverage of AppSensor event, attack and response events can be as little or as much as is imported from logging or signaling, but is dependent upon the customization options of the tool. But with all of these model examples, code can be developed to produce a custom dashboard by the organization to suit their own business needs.
Chapter 29 : Application Vulnerability Tracking Introduction
Software bug/defect/vulnerability tracking systems can also consume AppSensor data to add intelligence for severity rating and prioritization. Knowledge about actual attacks and how attackers may be getting close to vulnerabilities scheduled for mitigation is valuable information. This class of software will usually have multiple methods of data import, and will be preconfigured to consume data from commonly used commercial and open source information security risk and vulnerability software.
Description
Application vulnerability tracking software usually supports a portfolio of projects or applications.
An open source tool in this area is ThreadFix130 that facilitates the import, aggregation, analysis and management of vulnerability data from security verification activities throughout the software development lifecycle. This has the additional capability of creating web application firewall (WAF) rules that can be deployed while vulnerabilities are being investigated, corrected, tested, deployed and verified.
The default dashboard in ThreadFix displays vulnerabilities grouped by severity and by most common by CWE156. It is possible to imagine how AppSensor data could be overlaid to provide insight into which types of vulnerability might be being actively targeted by different groups of users.
Figure 29 and Figure 30 on the following page, illustrate a mock overlay of attacks grouped by user group. Note the logarithmic scale. These could potentially also be made into more detailed reports. ThreadFix and other tools in this class of software do not yet support this capability, but could be extended to do so.
In practice, some of the most common CWEs such as configuration and information leakage issues may not be included in AppSensor attack detection, and it may not be simple to provide a mapping from detection points to CWEs.
ThreadFix Dashboard Showing Mock Up of CWE vs Attack Chart Overlay
Detailed View of Chart Overlay Mockup
Since tools like this also import static analysis (code review), a more useful possibility is identifying attacks against particular filters, modules or functions. These could be mapped during the detection point design specification stage, and saved in AppSensor logs or included in AppSensor event signaling (see Signaling Data Exchange Formats and File Data Logging Format in Part VI : Reference).
Similarly if application logging records the entry point (i.e. URL path), this could be used to cross reference attacks and vulnerabilities. A mock-up of this addition to ThreadFix’s vulnerability report drill down is shown below.
Mockup Illustrating How URL Paths Could be Used To Match Vulnerabilities Identified Through Security Scanning Correlate with Where Attacks are Occurring
AppSensor coverage
Coverage of AppSensor event, attack and response events can be as little or as much as is imported from logging or signaling, but is dependent upon the customization options of the tool.
Share with your friends: |