Method and system of hardening applications against security attacks

In one aspect, computerized method for hardening security of an application includes the step of modifying a set of instructions of an application to include at least one sensor adapted to capture a set of information snapshots from within the application in a running state. The method includes the step of analyzing, from within the application, the set of information snapshots from the at least one sensor. The method includes the step of detecting a presence, a status, and a configuration of a security defense mechanism based on an analysis of the information snapshots; invoking an appropriate hardening action to improve the security defense mechanism of the application.

BACKGROUND

This description relates to the field of hardening applications to improve resilience against security attacks on computer systems.

2. Related Art

For years, organizations have struggled to block attacks on vulnerable software applications. Application software controls finances, healthcare information, legal records, and even military defenses. Further, application software is growing and interconnecting at an unprecedented rate. This increasing reliance on software combined with common vulnerabilities and rapidly increasing complexity creates significant business risk stemming from the use of software applications. Accurately detecting and defending against attacks on these applications can minimize the likelihood of a breach even when the underlying software contains vulnerabilities.

Protecting the application software can involve a variety of different security defenses, such as input validation, authentication, authorization, encryption, escaping, parameterization, tokenization, and many others. For example, the application software not properly protect against SQL Injection attacks with escaping or parameterization. Or the application software may be missing access control checks designed to ensure that users only access authorized data and functions. In another example, the application software can include a logging capability to ensure that records of security-relevant events are captured for later analysis. The logging capability may be missing, weak, disabled, misconfigured, or not used properly. In this case, the application would not be able to capture the security-relevant events necessary identify attacks, perform intrusion analysis, or any other activity requiring complete logs. Other defenses may be missing, weak, disabled, misconfigured, or not used properly and would be apparent to one of ordinary skill in the art. Therefore, there exists a need fore better method of performing attack detection and protection in software applications and services.

BRIEF SUMMARY OF THE INVENTION

In one aspect, computerized method for hardening security of an application includes the step of modifying a set of instructions of an application to include at least one sensor adapted to capture a set of information snapshots from within the application in a running state. The method includes the step of analyzing, from within the application, the set of information snapshots from the at least one sensor. The method includes the step of detecting a presence, a status, and a configuration of a security defense mechanism based on an analysis of the information snapshots. The method includes the step of invoking an appropriate hardening action to improve the security defense mechanism of the application.

Optionally, the application hardening can be combined with an application vulnerability detection process or an application attack detection and prevention process. The application includes a web application, a web service, an application programming interface (API), a mobile application, a client application, a server application or an embedded application. The application includes a set of components comprising at least one of a runtime platform, a virtual machine, a set of application servers, an application framework, an application library, or an application module. The set of information snapshots can include information from a presence of set of security defenses, the application library, the application framework, a software-architecture detail, an application state, a backend connection, or an application configuration information. The hardening action includes an addition of a missing defense, a defense enhancement, an enabling of a defense, a modification of a defense configuration, or an addition of an invocation of the defense in a specified location of a set of code of the application. The hardening rules be specified in an external configuration. The step of invoking the appropriate hardening action to improve the security defenses of the application further includes the step of modifying a specified portion of code of the application for at least one method in the application; invoking at least one method to change a state or a configuration of the application replacing the specified portion of code for at least one method in the application; and modifying an application file or another data store associated with the application to link a new security defense code into the application. The security defense mechanism includes an authentication and forgery check, an authorization check, an input validation, an output escaping or encoding process, a data encryption, a logging process HTTP mechanism, a connection security process, a fraud prevention process, an integrity check, or security filters. The security defense mechanism can be centralized in the application module. The security defense mechanism can be distributed across the application code. The security defense mechanism can be enforced by an external component. The external component includes a web server application server, network switch, network router network firewall, operating system, or a web application firewall. The security defense mechanism can be located in the application platform, the application server, the application framework, the application library, the application module, the set of components used by the application, or a custom code segment of the application. A user can define a custom hardening action for the application. The step of modifying the set of instructions of the application to include at least one sensor adapted to capture the set of information snapshots from within the application in a running state further can include the step of dynamically patching the code segment at a run-time of the application. The code segment to be patched comprise a software component of the application or the application library.

The Figures described above are a representative and are not an exhaustive with respect to embodying the invention.

DETAILED DESCRIPTION

Disclosed are a system method, and article of manufacture for hardening applications against security attacks. The following description is presented to enable a person of ordinary skill in the art to make and use the various embodiments. Descriptions of specific devices, techniques, and applications provided only as examples. Various modifications to the examples described herein will be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the various embodiments.

Example Definitions

Attack can be any attempt to destroy, expose, alter, disable, steal, extract data from, corrupt, interfere with, gain unauthorized access to, or make unauthorized use of an asset (e.g. a computer application, etc.).

Application includes all forms of software code executing on computer hardware, including any virtualization hardware technology. An application could be a web application or web service running on a web or application server, a mobile application running on a device, a client or server application running on a desktop computer, or any other form of software running in a car, refrigerator, airplane, weapon system, phone, drone, or robot.

Bot can be a type of malware that allows an attack to take control over an affected computer.

Common Vulnerabilities and Exposures (CVE) can be a system that provides a reference-method for publicly known information-security vulnerabilities and exposures.

Configuration information can include property files, xml documents, and initialization files, and the like.

Honeypot mechanism can be a computer security a mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems.

Library can be a collection of subprograms, modules, or components.

Sensor is a piece of executable code that extracts data from within an executing application. A sensor can also be used to alter the execution of the application. A sensor is wrapped in exception handling logic that ensures that the application's execution is not unintentionally modified. A sensor can be a passive sensor, an active sensor, and a response sensor.

SQL injection is a code injection technique used to attack data-driven applications, in which nefarious SQL statements are inserted into an entry field for execution.

Throwing an exception can include creating are exception object and handing it to a runtime system.

Virtual patch can be an easily deployed implementation of a security policy meant to prevent an exploit from occurring as a result of a newly discovered vulnerability.

Example Systems and Processes

Referring now toFIG. 1, a schematic illustration of an example system100in accordance with implementations of the present disclosure can include a plurality of clients108,110, and a computer system114, according to some embodiments. The computer system114can include server102and a database104. In some implementations, the system100can represent a client/server system supporting multiple computer systems, (e.g., computer system114) including one or more clients (e.g., clients108,110) and/or one or more servers (e.g., server102) that are connectively coupled for communication with one another over a network106. In some implementations, the clients (e.g., clients108,110) can be directly connected to the one or more servers (e.g., server102) (without connecting by way of network106).

Clients108,110can represent various forms of processing devices including, but not limited to, a desktop computer, a laptop computer, a handheld computer, a personal digital assistant (PDA), a cellular telephone, a network appliance camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or a combination of any two or more of these data processing devices or other data processing devices. Each client108,110can access application software on the server102.

In some implementations, the client devices108,110can communicate wirelessly through a communication interface (not shown), which can include digital signal processing circuitry where necessary. The communication interface can provide for communications under various modes or protocols, such as GSM voice calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others. For example, the communication can occur through a radio-frequency transceiver (not shown). In addition, short-range communication can occur, such as using a Bluetooth, WiFi, or other such transceiver.

In some implementations, the system100can be a distributed client/server system that spans one or more networks such as network106. The system100can be a cloud computing system. The network106can be a large computer network, such as a local area network (LAN), wide area network (WAN), the Internet, a cellular network, or a combination thereof connecting any number of mobile clients, fixed clients and servers. In some implementations, each client (e.g., clients108,110) can communicate with the server102via a virtual private network (VPN), Secure Shell (SSH) tunnel, or other secure network connection. In some implementations the network106can include the Internet, a wireless service network and can include the Public Switched Telephone Network (PSTN). In other implementations, the network106can include a corporate network (e.g., an intranet) and one or more wireless access points.

The server102can represent various forms of servers including, but not limited to a web server, an application server, a proxy server, a network server, or a server farm. For example, the server102can be an application server that executes software accessed by clients108,110. In operation, multiple clients (e.g., clients108,110) a communicate with the server102by way of network108. In some implementations, a user can invoke applications available on the server102in a web browser running on a client (e.g., clients108,110). Each application can individually access data from one or more repository resources (e.g., database104). For example, the server102can access database104.

Applications can be provided either by the hosted computing system or from third party systems that are separate from the hosted computer system. Such applications can include services that provide information about locations of various users (as determined, e.g., from GPS can their mobile devices), services that provide news and weather feeds, and other such services. The applications can also include, for example, email and other messaging applications, productivity applications such as spreadsheets and word processors, mapping applications and mash-ups of various applications that can be presented together in a single presentation.

FIG. 2is a block diagram of security hardening system200in accordance with implementations of the present disclosure that can detect attacks and invoke appropriate hardening actions in the software, according to some embodiments. Security-hardening system200can be implemented as a client/server system, an example of which can include system100ofFIG. 1. Security-hardening system200can be implemented using client108, network106, and computer system114that includes server102and database104.

Security-hardening system200includes a policy-management module210, an instrumentation module220that is used to instrument an application230, an analysis module240that collects and analyzes data from the instrumented application230, a security module250that takes actions to harden the security of the instrumented application, and an explorer module260that enables an administrative user to manage the results of the hardening. Security-hardening system200car its components can be written in or based on any appropriate computer language including Java, C, C++, Visual Basic, Perl, Python and others. Security-hardening system200can reside on single or multiple computers. Security-hardening system200can include an interface for communicating with other computer systems. It is noted that application230can be a web application, a web service, an application programming interface (API), a mobile application, a client application, a server application, an embedded application, etc.

Security-hardening system200can operates based on a set of security rules specified with policy-management module210. These security rules control the process of hardening the security of application230by security-hardening system200. The security rules have a two-fold purpose. First, the security rules list specific conditions that, when satisfied, indicate the need for adding, enhancing, enabling, modifying the configuration of, or adding invocations of a defense for application230. More specifically, security rules identify a pattern of information snapshots that indicate a need for security hardening. Second, the rules may define the source and type of the information to be captured in an information snapshot application230. This can include, inter alia: the presence or absence of security defenses, libraries and frameworks, software, architecture details, application state, backend connections, configuration information, and/or any other information relevant to the operation of applications security defenses. In particular, the rule identifies can specify the sensors to be instrumented into the application by instrumentation module220. Multiple rules can be further grouped into policies. It is noted that a security policy can be a collection of one or more security rules that are designed to handle a particular type of hardening. Security polices can be designed to ensure that security is enforced for particular components and/or URLs. For example, a user may create a policy that ensures defenses are in place for attacks such as cross-site scripting, SQL injection, cross-site request forgery, padding oracle attacks, brute force attacks, and attempts to bypass authorization.

Security-hardening system200inserts passive, active, and response software sensors314into each of the methods designated by the events in the security rules. This can be a process referred to as ‘instrumentation’. During execution of application230, each inserted passive sensor generates an information snapshot that is collected and analyzed by analysis module240at various times during the operation of the application. This collected data, referred to as an ‘information snapshot’, is a collection of data collection from the application being hardened. For example, the information snapshot can include various details extracted from the application, such as whether defenses are enabled, how defenses are configured, details of algorithms or security rules enforced, libraries or components used, frameworks used and/or other information related to the security of the application. Some sensors may gather information by invoking methods anywhere within the application stack to extract details.

Analysis module240collects the generated events from application230and analyses the data for the need for hardening. The analysis may be performed during the execution of application230, before the application runs, and/or after the application has completed its execution. In one example, analysis module240collects the generated information snapshots.

When analysis module240determines that a particular hardening rule has been satisfied (e.g. the rule criteria are matched), security-hardening system200directs the application to take one or more hardening actions. Hardening actions are carried out by the security enhancing code. In some examples, this security enhancing code may be instrumented into the code and in other cases may be part of Security-hardening system200.

Hardening actions can include, inter alia: adding a missing defense; enhancing a defense; enabling a defense; modifying the configuration of a defense; adding invocations of the defense in the code; etc.

FIG. 3is a block diagram that illustrates a view of security-hardening system200as it instruments application230, according to some embodiments. In particular,FIG. 3is directed to the instrumentation of application230with the help of policy-management module210and instrumentation module220.

Application230can include number of software components. In some implementations, application230includes application code307, compiled libraries308run-time libraries309container classes310, virtual machine311, and other software components312. These components can also include methods or subroutines313, such as shown in more detail for application code307. A method and/or a subroutine can include a sequence of programming statements to perform an action, a set of input parameters to customize those actions and/or a return value. In object-oriented technologies, a n method can be associated either with a class (e.g. a class method or a static method) or with an object (e.g. an instance method). Methods provide a mechanism for accessing and manipulating the encapsulated data stored in an object.

As provided supra, programming flaws in methods and/or subroutines within application230can render application230vulnerable to attacks and/or security breaches. To harden application230against said attacks, security-hardening system200inserts sensors into the methods of application230. The inserted sensors gather information snapshots from application230.

The process of inserting sensors in application230is referred to as ‘instrumentation’. Security hardening system200uses policy-management module210to govern the process of instrumenting application230. In particular, with policy-management module210, an administrative use can create and/or edit one or more security rules302that specify methods within application230that require instrumentation with one or more sensors. In addition, security rules302can also specify a pattern that signals a presence of a security attack, as well as, other information, such appropriate response actions.

Security-hardening system200uses instrumentation module220to insert passive, active, and response software sensors314in application230according to a set of security rules302specified with policy-management module210. In particular, instrumentation module220includes an instrumentation manager304and instrumentation agent305. Instrumentation agent305processes security rules302. Security rules302specify the methods requiring instrumentation and/or direct instrumentation agent305to install sensors into the specified methods of application230. Hardenings320(e.g. hardening instructions) can be associated with passive, active, and response software sensors314. Hardenings320can implement various hardening processes such as process400, process1900, etc.

It is noted that in some embodiments, not all methods need to be instrumented. For example, some methods are not relevant to security. Accordingly, there may be little point of instrumenting them, because instrumentation carries additional performance overhead. In contrast, other methods are relevant to many different security attacks and therefore need to be instrumented to determine how to protect against these attacks. Security rules302identify such methods as well as all other sources of security relevant information within the application and also specify conditions or patterns that, when triggered, indicate presence of hardening opportunities in the application.

Instrumentation agent305instruments application230by inserting passive, active, and response software sensors314into the methods specified by event objects in security rules302. In some implementations, instrumentation agent305changes the code of application230, but does not change any fields in the instrumented classes or methods. Therefore, no data, such as flags, bits, indicators, links, and/or any other is added in the instrumented methods or classes. As a result, execution of application230is not adversely affected. In other example embodiments, instrumentation agent305changes the state associated with methods or classes of application230to facilitate data tracking.

To facilitate rule creation and maintenance, rules may be en to enable instrumentation of multiple sources of security defense information in one application. By way of example, instrumentation can include parsing the binary codes of an application software as the binary codes are being loaded from a storage device to inject a monitor code. The parsed software code can then be executed by one or more hardware processors. The injection sites may be specific to the particular application software. Sensors can, gather information from the code of an application, configuration file libraries, frameworks, backend connections, and by interrogating the application using application programming interfaces (APIs).

Instrumentation agent305can instrument methods dynamically, statically, or by using a hybrid mode of instrumentation. Dynamic instrumentation includes inserting sensors in methods of application230during execution of application230through the use of an API designed for that purpose (e.g. a Java Instrumentation API, etc.). Another type of instrumentation is static instrumentation. In a static instrumentation example, the code of application230is instrumented with passive, active, and response software sensors314before application230begins to execute. In this example instrumentation agent305changes the source, object and/or executable code of application230to include the instructions or passive, active, and response software sensors314used for monitoring. In some implementations, hybrid instrumentation of application230is also possible, such that some methods of application230are instrumented statically, while other methods are instrumented dynamically when application230is executing.

Instrumentation module220can insert a number of different sensors into application230. These sensors generate information snapshots whenever a sensor is invoked. Analysis module240collects the generated events (e.g. all generated events, etc.) during the operation of application230. There exist three general types of sensors—“passive” sensors, “active” sensors, and “response” sensors. Attack analysis can occur throughout the execution of the application based on the data gathered from the sensors.

Passive sensors generate information snapshots that are analyzed by analysis module240. Passive sensors are used to collect various types of data from the executing application230that is later used during hardening analysis. For example, a passive sensor informs analysis module240to capture an information snapshot. Information snapshots can include information associated with application230, including, inter alia: the presence, status, and/or configuration of a security mechanism.

An active sensor implements one or more actions to gather data from the application. Active sensors can interrogate the application environment, configuration, framework and/or codebase to gather data. One type of active sensor monitors for Hypertext Transfer Protocol (HTTP) requests and responses and application server configuration. HTTP request and response sensors capture the HTTP traffic either received at and/or transmitted from the application server. HTTP response and request sensors may then use the captured HTTP traffic as part of attack analysis. For example, examining the HTTP response can enable some implementations to quickly and accurately identify security attacks such as, for example, parameter tampering, session hijacking and/or missing cross-site request forgery tokens. Application server configuration sensors, on the other hand, can access properties files, XML files, APIs, and other sources of configuration data and use that data as part of the attack analysis, such as the misconfiguration of defenses, improperly protected files, unencrypted passwords and many others. Another type of active sensor interrogates backend connections to determine their security characteristics. Other type of sensors are also possible to utilize as well. The information snapshots from these sensors may be combined with data from other sensors when identifying hardening opportunities.

A hardening action (e.g. implemented using hardenings320) responds to a detected opportunity to improve the security defenses of the application. The range of possible hardening actions can include all of the hardening activities detailed above, as well as others. These hardening actions may be instrumented into the target application (e.g. application230) and/or be delivered as standalone code to be invoked at runtime. Multiple hardening actions can be used to handle the different necessary opportunities to strengthen application defenses.

Performance of the sensor and hardening action installation and operation can use in the real-time operation of the security hardening system. One technique used to enhance the performance of the instrumentation process is to cache the required code changes as the sensors are installed in the codebase. As long as the policy does not change, the cached changes can be applied rather than reapplying the rules to the entire application each time the application starts. For example, the process of instrumenting the code such that application230starts can be sped up by caching.

FIG. 4illustrates an example security-hardening process,400, according to sore embodiments. In step402, process400can modify a set of instructions of an application to include at least one sensor adapted to capture a set of information snapshots from within the application in a running state. In step404, process400can analyze, from within the application, the set of information snapshots from the at least one sensor. In step406, process400can detect a presence, a status, and a configuration of a security defense mechanism based on an analysis of the information snapshots. In step402, process400can invoke an appropriate hardening action to improve the security defense mechanism of the application.

FIG. 5is a block diagram of an example structure of a security rule302, according to some embodiments. Security rule302is a complex data structure. Security rule302can include various fields. Security rule302can include a security-rule identifier field502. Security rule identifier field502is a text string and/or a number. Security-rule identifier field502uniquely identifies the security rule among other security rules. For example, security-rule identifier field502can be set to ‘security rule #1’. Security rule302can also include a category field503. Category field503provides the general category of the defense that security rule302is designed to improve, such as, inter alia: authentication, session management, authorization, validation and encoding, secure communications, encryption, caching, availability, etc.

In addition, security rule302can include a description field504. Description field504provides the general description of the security rule and/or its purpose, such as, inter alia: “this security rule detects missing access controls in the application configuration and enables them with a safe configuration.” Furthermore, security rule302can include an importance-level field505. Importance-level field505indicates overall importance level of the defense improvement. For example, importance levels can be set to levels, such as ‘low’, ‘medium’, or ‘high’. Security rule302can also include, a guidance field507that stores guidance to the user for handling the detected hardening opportunity.

In addition, security rule302includes a set of criteria508that comprise a pattern that is being detected by the security rule302. These criteria can combine different types of events and application state information. When the state of application230meets the criteria defined by the rule, security-hardening system200invokes the associated hardening actions. Accordingly, security rule302can include associated hardening instructions516.

Security rules302can check for a number of patterns that indicate weak or missing defenses, such as, inter alia: missing, weak, broken, or misconfigured communications, input validation, authentication authorization, encryption, logging, output escaping, parameterization, parser configuration, application server configuration, HTTP headers, and many more.

For example, security-hardening system200can check whether application230is properly defended against SQL injection. In this example, security-hardening system200analyzes the application to determine if SQL injection defenses are present, correct, properly invoked, and/or used in correct locations. If a SQL injection defense is determined to be missing or weak, then the hardening actions include enabling or strengthening the SQL injection defenses.

In another example, a security rule can be specified to detect a cross-site request forgery attack. In this example, the rule indicates how to check the application configuration to determine if an appropriate token check is applied to transactions. If the defense is determined to be disabled, the rule can enable that defense by invoking an API or modifying a configuration setting within the application.

While the foregoing is directed to examples of specific security rules, other security rules may be devised without departing from the basic scope thereof. It is noted that security rules302may be written to analyze and enhance any type of defense in application230.

In another example embodiment, security-hardening system200can dynamically enhance the security of application based either internal or external conditions. Adaptive hardening is hardening that is performed dynamically as the application runs. A variety of runtime conditions detected by the invention can trigger enhanced defenses. For example, security-hardening system200can enable additional authentication defenses when it is determined that attackers are targeting the application. In additional examples, security-hardening system200can increase log levels, use stronger encryption, enable deeper attack detection technology, or require users to have increased privilege levels. Any defense can be enhanced at runtime by the invention, and additional examples will be obvious to one skilled in the art.

FIG. 6is a block diagram of the security-hardening system, according to some embodiments. Analysis module240begins to analyze the collected information snapshots as it is collected. Correlation module604can perform correlation between events. In some examples, this partial analysis can indicate required hardening. This can prevent further processing. In other examples, analysis can continue throughout the operation of an application, detecting hardening opportunities. In some examples, hardening can be indicated after an attacker has already been successful in exploiting the application. Security-hardening system200can utilize an explorer module260to manage the application hardening process across one or more applications. The explorer module260can include a browser module608and a configuration module609. The browser module608provides a graphical user interface for viewing hardening configuration and results. The configuration module609is used to change the desired hardening configuration for one or more applications. Hardening module610can implement the various hardening functionalities provided herein (e.g. process400, process1900, etc.).

FIG. 7illustrates an example of how analysis nodule detects a hardening opportunity for XSS prevention, according to some embodiments. Information snapshots from HTTP analysis and configuration files are used to detect an opportunity to enable the X-XSS-Protection HTTP header. Because the header is not present in HTTP responses and is not configured properly, the hardening action to enable that protection is invoked, thus modifying the application configuration at runtime. Other rules rely on different sensors and include a custom detection algorithm.

The security module250takes action from within the instrumented application230to add a defense enhance a defense, enable a defense, codify the configuration of a defense, or add an invocation of a defense where needed in the code. Other possible actions to harden an application for security will be obvious to one skilled in the art. For example, if a standard cross-site scripting defense is available, such as an output escaping defense, the security module could invoke the necessary code to enable that defense. Similarly, the security module could add a new output escaping module to an application and then add code to all the locations in the application to invoke the view module to defeat cross-site scripting attacks. In another example, the security module could replace a faulty output escaping module with one that properly escapes data.

Security-hardening system200can utilize an explorer module260to manage the application hardening process across one or more applications. The explorer module260can include a browser module608and a configuration module609. The browser module608provides a graphical user interface for viewing hardening configuration and results. The configuration module609is used to change the desired hardening configuration for one or more applications.

FIG. 8is a screen-shot illustrating an example attack800identified by analysis module240, according to some embodiments. The attack800includes information associated with an attack pattern specified by the rule. The attack800includes data from one or more events received from the instrumented application230. Attack data801can include information about the type of the event, context associated with the event, the method that generated the event as well as data802associated with the method. This data802can include input parameters, output values, and stack803. In short, the event field801can include all or at least some of the information associated with the event, as described with respect toFIG. 4.

FIG. 9is a flowchart illustrating example steps900that can be executed by security hardening system200, according to some embodiments. In the optional step915, application230is instrumented with one or more sensors. Security-hardening system200uses instrumentation module220to instrument application230based on the security rules302. In this step, application230is instrumented statically because it has not begun execution yet. In step920, application230begins execution. In the optional step925, application230is instrumented dynamically during its execution. As with static instrumentation, security-hardening system200uses instrumentation module220to instrument application230with sensors based on the requirements set forth in security rules302. In step930one of application's230methods is invoked. If the called method has been instrumented with one or more sensors (step935), then the installed sensor(s) in that method generate at least one the event (step940). If the method is not instrumented, then an event is not generated and application230continues its execution. In step945, the generated event is stored with other events in analysis module240. In step950, analysis module240analyzes the stored events and detects any possible attacks based on the analysis. If at least one attack is detected (step955), analysis module240identifies a hardening opportunity (step960). The explorer module260enhances application230with hardening (step965). Notably, generation of attack reports and browsing, of results can occur while application230is executing or after it has completed execution. Therefore, a user can wait until application230has completed its execution to browse the results generated by security-hardening system200. Alternatively, or in addition, a user can browse the results or be alerted about existence of attacks immediately after vulnerabilities are detected and/or while application230is still executing.

FIGS. 10-17are screen-shots illustrating various aspects of an administrative interface used for accessing security-hardening system200, according to some embodiments. In particular,FIGS. 10 and 11illustrate various aspects of a user interface used for configuring policies and rules for security-hardening system200, according to some embodiments. This interface, may be displayed to a user by the policy module210. It is noted thatFIGS. 10-17include reference to WhiteCell as an example proprietary technology security service that implements various security technology that enables software applications to protect themselves against cyberattacks. However, other technology security services, such as those provided by Contrast Security®, can be utilized in lieu of WhiteCell.

FIG. 10is a screen-shot illustrating an example Graphical User Interface (GUI)1000for an administrative interface used for accessing security-hardening system200, according to some embodiments. The GUI1000includes various fields that enable an administrative user to specify security policies1001for application230. Each security policy includes one or e security rules1002designed to detecting a particular type of application attack230. In essence, a security policy is a collection of one or re security rules that are designed to identify one or more related attacks. Security polices can also be designed to ensure that security is enforced for particular components. For example, a user may create a policy that uses instrumentation to add, modify, enable, replace configure, or otherwise affect security defenses within the application. Other types of policies would be apparent to one of ordinary skill in the art and would depend on the specifics of a particular application.

FIG. 11is a screen-shot of an example GUI1100used for selecting and managing security rules, according to some embodiments. One of ordinary skill would recognize that the GUI1100is only exemplary and may allow security rules to be managed across a port of applications in a variety of ways.

FIGS. 12-18are screen-shots illustrating various aspects of a user interface used for reviewing results produced by security-hardening system200, according to some embodiments. This interface may be displayed to a user by the explorer module260.

In particular,FIG. 12is a screen-shot of an example GUI1200for browsing attacks identified by analysis module240, according to some embodiments. The GUI1200enables an administrative user to browse and review attacks1202identified by security-hardening system200. The traces (e.g. traces606ofFIG. 6supra) may be searched and sorted in a variety of ways (e.g. by vulnerability type, time, source IP address, attack content, severity, and more). By clicking on links to individual attacks1202, the user can further drill down to the specific details of each collected attack. It is noted that upon further review, an administrative user may decide to perform various operations such as creating an exception, block an IP address, etc.FIG. 13illustrates an example screen shot illustrating aspects of a user interface used for reviewing results produced by security-hardening system200, according to some embodiments.

FIG. 14is a screen-shot of an example GUI1400for reviewing an individual attack selected from the GUI1300. The GUI1400includes a summary section1401that provide a high-level summary of the detected attack. For example, the summary section1401can include a short explanation of the attack's significance. In addition, the summary section1401can include an explanation of how the attack targeted the application.

FIG. 15is a screen-shot of an example GUI1500that provides the user with further detail about a detected attack report that was discussed with respect toFIG. 14, according to some embodiments.FIG. 15includes various fields1501that provide further detail to user about the one or more events that triggered within the rule, according to some embodiments. For example, fields1501may include a class and a method associated with the triggered event. In addition, fields1501may include the method's arguments, the return value of the method, and the stack trace at the time of the method's invocation. Furthermore, fields1501may provide the user with any other information associated with the triggered event, such as information about any tracked data associated with the event.

Security-hardening system200can automatically generate a security rule to be enforced by an external device such as a web application firewall. This rule can be pushed automatically to the external device or could be handled b another process. The external security device can help mitigate an attack or the impact of a successful attack.

In another implementation, security-hardening system200automatically protects applications with known vulnerabilities. For example, the detection system can recognize that a particular application is using the Struts (e.g. Apache Struts, etc.) application framework (e.g., a standard in developing Web applications), and that a vulnerability exists in the manner which the Struts application framework is being used by the particular application. Accordingly, the system may automatically deploy a Struts-specific shield to prevent the known vulnerability from being exploited. A shield is a custom type of sensor that is instrumented into one or more locations in application230to prevent a vulnerability from being exploited. This example approach can be used to provide a shield for vulnerabilities in the custom code of the application.

One of ordinary skill would, of course, recognize that interfaces inFIGS. 11-18are only exemplary and may each include fewer or more fields related to the details of security rules or detected hardening opportunities, depending on the specific details of rules or detected attacks.

Referring now toFIG. 19, example steps that can be executed in accordance with implementations of the present disclosure be described, according to some embodiments. The example steps ofFIG. 19can be executed using one or more processors coupled to a computer-readable storage medium at a computer system (e.g., the computer system114including, server102) and/or a client device (e.g., the client devices108,110).

In step1910, process1900can modify instructions of application to include at least one sensor that is configurable to generate an event indicator wherein event indicator includes at least some data associated with event. In step1915, process1900can store the event indicator with other stored event indicators generated by the at least one, sensor during the execution of the application. In step1920, process900can analyze, from within the application, the stored event indicator. In step1925, process1900can detect a presence of at least one vulnerability in the application based on the analysis of the stored event indicators. In step1930, process1900can report the presence of at least one vulnerability. In step1935, process1900can detect a presence, a status, and a configuration of a security defense mechanism based on an analysis of the information snapshots. In step1940, process1900can invoke an appropriate hardening action to improve the security defense mechanism of the application.

It is noted that security-hardening system200can be used in a variety of different environments and/or for different purposes. For example, an analyst can run application230with security-hardening system200to find out whether it is under attack, being exploited, or has vulnerabilities. The analyst may be able to run application230without requiring a special setup, environment or source code. The resulting output of security hardening system200would detail the security posture of the application.

In another example, an application owner without security knowledge carp run application230with security-hardening system200enabled, perhaps only focused on their particular code. In this example, security-hardening system200would produce warnings about identified and enhanced hardening opportunities ire the application.

And in yet another example, a security expert can add custom sensors and/or security rules to security-hardening system200, thus tailoring the security hardening system's engine to the types of defense enhancements that are specific to the organization's business and technology. The expert can use security-hardening system200to gather information about how application230responds to simulated attacks during security testing. For example, security-hardening system200can report any violation of the rules involving any technology from application230. Even patterns of code execution that are not typically thought of as defense problems can be identified by the security hardening system, such as unusual user behavior or atypical exception occurrences.

In some implementations, security-hardening system200can be used to protect applications sold and/or distributed from an application store. Such an application store may be any location where one or more software applications are available to users for activation or download. Examples of applications can include video game programs, personal information management programs, programs for playing media assets and/or navigating the media asset database, programs for controlling a telephone interface to place and/or receive calls, etc., These applications can be first developed by third parties and then uploaded to the application store, where they can be downloaded by the users of the store. Either the store operator or the end user ray use the security hardening system to defend the applications being downloaded.

Referring now toFIG. 20, a schematic illustration of example hardware components that can be used to execute implementations of the present disclosure is provided, according to some embodiments. The system2000can be used for the operations described in association with the methods described in accordance with implementations of the present disclosure. For example, the system2000can be included in the application server102executing security-hardening system200. The system2000includes a processor2010, a memory2020, a storage device2030, and an input/output device2040. Each of the components2010,2020,2030, and2040are interconnected using a system bus2050. The processor2010is capable of processing instructions for execution within the system2000. In one implementation, the processor2010is a single-threaded processor. In another implementation, the processor2010is a multi-threaded processor. The processor2010is capable of processing instructions stored in the memory2020or on the storage device2030to display graphical information for a user interface on the input/output device2040.

The memory2020stores information within the system2000. In one implementation, the memory2020is a computer-readable medium. In one implementation, the memory2020is a volatile memory unit. In another implementation, the memory2020is a non-volatile memory unit. Memory1520stores data, which typically comprises security rules, instructions, algorithms, code, or any other directives operable to enable the system to detect vulnerabilities. Stored data can be any suitable format such as, for example, an XML document, a flat file, CSV file, a name-value pair file, an SQL table, an HTML page a text message, or others. In addition, data can include instructions written in or based on any appropriate, computer language including C, C++, Java, Visual Basic, Perl, and others.

The storage device2030is capable of providing mass storage for the system2000. In one implementation, the storage device2030is a computer-readable medium. In various different implementations, the storage device2030can be a floppy disk device, a hard disk device, an optical disk device, or a tape device. The input/output device2040provides input/output operations for the system2000. In one implementation, the input/output device2040includes a keyboard and/or pointing device. In another implementation, the input/output device2040includes a display unit for displaying graphical user interfaces.

To provide for interaction with user, the features can be implemented on a computer having a display device such as CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.

The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or are Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include e.g., a LAN a WAN, and the computers and networks forming the Internet. In addition, security-hardening system200can also operate in a hosted computing system, often referenced as “the cloud.” Security-hardening system200can be stored and executed from a server system, rather than from a client device, thus allowing security-hardening system200to be shared easily between users. In addition, security-hardening system200can also be implemented to operate with wireless handheld and/or specialized devices. The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described cane. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. However, one skilled in the art would recognize that any application, whether it embedded, mobile, desktop, server, or cloud, could use the described technology to detect vulnerabilities. Accordingly, one can use the described detection technology to monitor the running application and get notifications when the application violates the established policies.

In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps can be provided or steps can be eliminated, from the described flows, and other components can be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

CONCLUSION