Cisco Secure Application Policies specify actions when an attack or vulnerability matches your defined criteria. They also determine what types of attacks and vulnerabilities are addressed. You can create and configure 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 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. 

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. 

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)

Cookie: HttpOnly: 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. 

Cookie: SameSite (C_SITE)

Cookie: SameSite: The SameSite attribute enables servers to prevent cookies from being sent with cross-origin requests (where Site is defined by the registrable domain). This provides protection against cross-site request forgery attacks (CSRF). 

Cookie: Secure (C_SECURE)

Cookie: Secure: A cookie with the Secure attribute is sent to the server only with an encrypted request over the HTTPS protocol. It is never sent with unsecured HTTP, and therefore cannot be accessed by a man-in-the-middle attacker. 

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

The X-Content-Type-Options response HTTP 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)

HTTP Header: Content-Security-Policy: The HTTP Content-Security-Policy response 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)

HTTP Header: X-Frame-Options: The X-Frame-Options HTTP response 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)The HTTP Strict-Transport-Security response header (HSTS) 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)

HTTP Header: X-XSS-Protection: The HTTP X-XSS-Protection 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)

Uncaught Exception: 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). 

Create a Security Policy 

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

  1. Click Policies > Create New Policy.
  2. From the Add Policy dialog, select the required criteria for the attacks in these fields:
    • Policy Type: Select Attack Policy to create a policy for a specific attack. Select Vulnerability Policy to create a policy for a specific vulnerability.
    • Name: Select the type of attack or vulnerability for which you require the policy.
    • 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.

    • Action: Select the action for this policy.
      • For Attacks: Select None for no notifications on the Attacks page; 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.
      • For Vulnerabilities: 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.

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

  3. Click Save.

Modify a Security Policy

To view and modify a policy for an attack or vulnerability, perform the following steps:

You can use the Search filter to search based on the values of the Name or Application Name fields.

  1. Click Policies.
  2. Select the application and the tier or service whose policy you want to modify.
  3. Click Attacks to view the list of attack policies. Click Vulnerabilities to view the list of vulnerability policies.
    At the bottom right corner of the page, you can view 5, 10, 20, or 50 policies in the list by selecting the Show<number of policies> dropdown. 
  4. Click the Modify icon. 
  5. Modify the required fields. 
  6. Click Update or click Delete Policy based on the requirement.