Cisco Secure Application Runtime policies define what runtime behaviors to ignore, detect, or block. The runtime events identify all the attacks and vulnerabilities and the action is taken based on the defined runtime policy. You can create and configure runtime policies to specify an action to mitigate the attacks and vulnerabilities. 

To monitor the security of the application, you must create policies. To create policies, you require the Configure permission for Cisco Secure Application. By default, Cisco Secure Application includes a runtime policy that provides the best detection of all the attacks and vulnerabilities, reducing the false positives.

Cisco Secure Application scans these types of attacks and vulnerabilities:

Attack TypeDescription

Local File Inclusion (LFI)

Software imports, requires, or includes executable functionality (such as a library) from a source that is outside the intended control sphere. 

Expression language Injection (EXPR)

The software constructs all or part of a code segment using externally-influenced input from an upstream component. However, it does not neutralize or incorrectly neutralizes the special elements that could modify the syntax or the behavior of the intended code segment.

For example, including an argument in a URL that the framework (such as Spring) uses directly to launch a command or perform some other malicious activity.

Malicious IP (Mal_IP)An IP tagged as malicious is detected interacting with an application service or tier.

Path Traversal (PATH)

Uses external input to construct a pathname that is intended to identify a file or directory that is under a restricted parent directory. However, the software does not properly neutralize special elements within the pathname. This may cause the pathname to resolve to a location outside of the restricted directory. 

Server-side Request Forgery (SSRF)The web server receives a URL or a similar request from an upstream component and retrieves the content of the URL. However, it does not sufficiently ensure that the request is sent to the expected destination.
Remote Code Execution (RCE)Triggers arbitrary code execution over a network. This occurs through the framework's backdoor, using content such as XML, JSON, and Java serialization.

Untrusted Deserialization (DESERIAL)

The application deserializes untrusted data without sufficiently verifying that the resulting data is valid. 

Vulnerability TypeDescription

Cookie: HttpOnly (C_HTTP)

A cookie with the HttpOnly attribute is inaccessible to the JavaScript Document.cookie API; it is sent only to the server. For example, cookies that persist server-side sessions do not need to be available to JavaScript, and should have the HttpOnly attribute. This precaution helps mitigate cross-site scripting (XSS) attacks. 

HTTP Header: X-Content-Type-Options (H_CONTENT)

This header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed. This provides a way to opt-out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured. 

HTTP Header: Content-Security-Policy (H_CSP)

This header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. 

HTTP Header: X-Frame-Options (H_FRAME)

This header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. 

HTTP Header: Strict-Transport-Security (H_STS)This header is used in a website to send information to the browsers that the website should only be accessed using HTTPS, instead of using HTTP. This header is used to prevent man-in-the-middle attacks or sensitive data leakage. 

HTTP Header: X-XSS-Protection (H_XSS)

This response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. 

Uncaught Exception (EXC)

This is a very common issue - the runtime generally has built in security detection mechanisms in the form of Exceptions that are often times not "caught" and/or "not logged" - or if they are - it's buried in a file that is not reviewed until days or weeks after a security breach has occurred. This reviews ALL security related Exceptions across the entire runtime and using the security policy can report and/or take other additional actions on the information. 

Vulnerable Libraries (LIB)

Detect all applicable vulnerabilities to the application's services and tiers as reported in the National Vulnerability Database (NVD). 

SQL: Non-parameterized Queries (SQL_PARAM)The software constructs all or part of an SQL command using externally-influenced input from an upstream component. However, it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to the downstream component.

Create a Security Policy 

To create a policy for an attack or vulnerability at runtime, perform the following steps:

  1. Click Policies > Create New Policy.
  2. From the Add Policy dialog, select the required criteria for the runtime in these fields:
    • Type: Select Runtime to create a policy for a specific runtime activity. 
    • Name: Select the required runtime activity.
    • Application: Select the application that includes the tiers or services on which you require to apply the policy.
      Select All to apply the policy on specified tiers or services of all the applications.

    • Tier: Select the required application-specific tier or service to apply the policy.
      Select All to apply the policy on all the tiers or services.

      AppDynamics recommends that you review the default policy and if needed create a policy for specific applications and tiers.

    • Default Action: Select the default action for this policy.
      • For the runtime activity that scans attacks, you can select Ignore for no notifications; select Detect to detect the attack and display the details on the Attacks page; or select Block to block a specific attack and to display it as Blocked on the Attacks page. 
        Click Attacks to view the list of all the ignored, detected, and blocked attacks based on the runtime policies.
      • For the runtime activity that scans vulnerabilities, you can select None for no notifications on the Vulnerabilities page; select Detect to detect the vulnerability and display the details on the Vulnerabilities page; select Patch to fix the security issues.
        Click Vulnerabilities to view the list of all the vulnerabilities found based on the runtime policies.

      Block is unavailable for some of the supported attacks and Patch is unavailable for some of the supported vulnerabilities.

    • Rules: Add the rules based on your requirement. The action that you specify within the rule supersedes the default action specified in Default Action.
    • Enable Policy: Select Yes to enable the runtime policy.
  3. Click Save.

You can click Attacks to view the list of all attack types and Vulnerabilities to view the list of all the vulnerability types.

Modify a Security Policy

To view and modify a policy, perform the following steps:

You can use the Search filter to search based on the values of the Name or Application Name fields. Here, Name is the name of the runtime policy.

  1. Click Policies > Runtime.
    You can view 5, 10, 20, or 50 policies based on the number that you select at the bottom right corner of the page in the Show<number of policies> dropdown.
  2. Click the Modify icon next to the required policy.
  3. Modify the required fields. 
  4. Click Update or click Delete Policy based on the requirement.