The Pulse APP has been monitoring our client’s server cluster since May 2017. The sample Monthly Performance Report generated by the APP includes a descriptive statistical and analytical review of the Pulse APP results (PRO server only) for the Month of June and for the Year-to-date (YTD—May and June).

The Data Table presents a statistical summary of the results of the current month (June) and Year-to-Date (YTD-May and June). The X (mean) and 2σ (2*Standard Deviation) are in Milliseconds, the # <2σ (count) is in integers, and the %E (% exceeded 2σ) is in decimals. The milliseconds refer to the response time for the target action to initiate, execute, and complete. The #2<2σ refers to how many individual measurements exceeded the 2σ threshold.

The Pulse App was developed in both ColdFusion and PHP programming languages. This versioning strategy was performed to accommodate client software requirements. The functionality and UI are identical for both versions.
The ColdFusion version is discussed in this specifications document. Figure 1 below is an idealized depiction of the most common App framework and architecture in a standard cloud configuration. For this version, deployment was to the GraphCube cloud environment.

Figure 1: Pulse APP Framework

Client Login Required
The APP is protected from unauthorized access via a required login. Clients (users) must first login to the APP via valid credentials. Login procedures are described in the Security Framework section of this document. A view of the login screen is displayed in Figure #2.

Figure 2: Pulse Login Screen

The APP automatically generates metrics by invoking 4 separate HTTPS-get requests to receiving files on the target web server every 15 minutes (see Figure 1 for a general overview of the metrics generation process). Clients can modify the automatic metrics generation schedule to meet specific client requirements. Each of these HTTPS-get requests starts and ends with a ColdFusion timer function to record the total time to make the request to the target and the time elapsed when/if the target receiving file responds. This response time is measured in milliseconds. The results are inserted into a SQL database on the APP host server for display in the Pulse chart (see Viewing Metrics section for an explanation of charting capabilities). The data inserted into the Host SQL include non-identifiable response-time data as specified in Table #1 below. Any request over 5 seconds is automatically timed out and recorded. Each of the 4 HTTPS-get requests are invoked by a CFC function and DO NOT display any data; the requests/responses are only timed. All CFM pages on the target utilize APP-only data source names and properties. These properties are designed to shield actual source names and paths for security purposes. Each target CFM and HTML receiving files are described below:

1. rM.cfm: this file invokes a standard CF function to get the current date and time and configure the date/time object in the mm/dd/yyyy hh:mm:ss format. No data/results are displayed.
2. rM.html: this file retrieves a selected image from the client public web site. No image or data are displayed.
3. rMSQL.cfm: this file uses special CF data source settings configured on the target server specifically for the APP. The tool queries only the first 100 rows of the sDT field in the pulse_tab table within the pulse SQL database. The pulse database includes only two fields: sDT (date/time) and ID (sequential integer) and 500 rows of random dates/times. The APP query only contains random dates/times and no other data. No queried results are displayed. The pulse SQL database was configured with a single user (pulse_app); this user has read-only access to data from the pulse database only.
4. rMOracle.cfm: this file uses the existing CF data source settings configured on the target server specifically for the APP. The tool queries only the first 100 rows of the sDT field in the pulse_tab table within the pulse Oracle database. The pulse database includes only two fields: sDT (date/time) and ID (sequential integer) and 500 rows of random dates/times. The APP query only contains random dates/times and no other data. No queried results are displayed. The pulse Oracle database was configured with a single user (pulse_app); this user has read-only access to data from the pulse database only.

To view App metrics, login to the app and the metrics for the current month are displayed. The response metrics are queried from the dX table on the APP host and loaded via json format into a FusionCharts JavaScript Zoom chart and a stacked Area Chart. The dX query is based on user parameters (start and end dates/times and Target server). The metrics chart is compatible for mobile, tablet, and desktop display. The chart display can be saved/exported in png, jpg, pdf, svg, or xls format (See Figure #3).

Figure 3: Sample Display Chart

The APP user interface (Figure 3) includes the following features which can be configured by the user:

1. Chart Selection (Zoom or Stacked Area).
2. Target Server (development, testing or production).
3. Start date/hour/minute for graph.
4. End date/hour/minute for graph.
5. Data table (hide or show).
6. Data download (Excel or CSV/Text).

As a reminder, the Pulse APP does NOT return any data to the client and does not include any process or functions that include sensitive or personally identifiable data. The APP only makes 2 generic queries (one to Oracle and one to SQL) to specially designed APP tables that include random dates only. The APP then measures the time required to complete the functions. Nevertheless, the APP has been configured with the following Security Details to prevent unauthorized access. Additionally, all Pulse APP receiving files are segregated into a /pulse folder.

Security Details

1. The Pulse APP (the APP) requires users login to the client site (or Graphcube cloud) with a valid account. This is accomplished on the APP; the APP can be used by any device (mobile, tablet, PC).
2. The APP requires an HTTPS connection for all processes. If an HTTPS connection is not established with the client (user), the APP is terminated. Accordingly, all app functions occur over an encrypted HTTPS connection using a PKCS #1 SHA-256 With RSA Encryption certificate from a trusted CA.
3. Clients (users) are allowed up to 3 attempts to login to Pulse. After 3 unsuccessful login attempts, client APP access is disabled for 24 hours, no further login attempts are allowed within this 24-hour period.
4. Login procedures include a series of security tests to prevent cross site forgery and cross site scripting and unauthorized APP access according to Table #2. NOTE: all tests in the table below must be passed for access to the APP.
   
   
   Table 2: APP Security Tests

   Test	Description of Security Test
   PRE 1	Username on login form required via CFFORM, no empty values accepted.
   PRE 2	Password on login form required via CFFORM, no empty values accepted.
   1	Ensure SSL connection, if no connection, redirected to HTTPS page, Test 1 value set to 0; if HTTPS connection is established, Test 1 value us set to 1.
   2	Ensure there is an encrypted Form Key. Note: we use AES 258 encryption of the server-generated CFTOKEN to insert a hidden form value (xKey) passed from the form to the login test. This ensures that the origin of the login is ONLY from the APP server page. If there is NO form key (xKey), the APP is terminated, Test 2 value set to 0.
   3	Ensure encrypted form xKey matches the CFTOKEN value. This is accomplished by the server decrypting the form xKey and comparing it to the CFTOKEN. This ensures that the login attempt originated from the APP server specified page only. If the xKey and CFTOKEN match, set the Test 3 value to 1, otherwise set the Test 3 value to 0.
   4	Ensure username is in login form. Supplement PRE 1 Test to account for cases where client JavaScript is disabled. If username is NOT included in the form, set Test 4 to 0, abort processing and redirect client to login form.
   5	Ensure password is in login form. Supplement PRE 2 Test to account for cases where client JavaScript is disabled. If password is NOT included in the form, set Test 5 to 0, abort processing and redirect client to login form.
   6	Ensure username is a minimum of 8 characters and less than or equal to a maximum of 120 characters. If the username meets these length parameters, set the Test 4 and Test 6 values to 1 each, otherwise abort processing and redirect client to login form.
   7	Ensure password is a minimum of 12 characters and less than or equal to a maximum of 50 characters. If the password meets these length parameters, set the Test 5 and Test 7 values to 1 each, otherwise abort processing and redirect client to login form.
   8	For the login processing, set a session variable named Strike to 1. Each time the login processing (login attempts) is accessed, increment the Strike variable by 1. Check the Strike variable and if Strike is less than 4, set Test 8 value to 1, otherwise set Strike variable to 0 and abort processing; disable further login by removing login content. Strike session variable set to 24 hours.
   FINAL	Check all test values (1—8). If the sum of all values is less than 8, abort processing according to above. If sum of all test values equals 8 and only 8, allow for login attempt to client or Graphcube/Cloud login page.

   
   
5. If FINAL login test equals 8 as specified above, attempt a login via HTTPS to client or Graphcube cloud login page. If login is successful, App returns a 96-character random and unique session variable. If no session variable is returned OR if an empty session variable is returned, processing is aborted and client is redirected to login page. If this session variable is returned from login and is exactly 96 characters, the Pulse APP extracts the session variable value and sets a final session variable as specified in Table #3.
   
   
   Table 3: APP Session Variable Specifics

   Action	Description
   1	Extract session variable value returned from client login
   2	Set session variable on Pulse server
   3	Set session variable on Pulse server, encrypt session variable value based on graphcube.com SSL
   4	Set session variable expiration to 2 hours or upon client logout (immediate expiration) or upon session (client browser) close (immediate expiration)

   
   
6. If and only if all parameters above are met and there is a valid Domain and Secure session variable, allow the APP to invoke the CFC to process the CFM/HTML receiving pages specified in Generating Metrics section above.
7. The CFC access to the client receiving files includes two security parameters passed to the receiving files as specified in Table #4. Note, the CGI Header Variable is NOT passed to the rM.html file since this file performs one and only one function: retrieval of a preloaded image from the pulse/images/ folder (see #9 below).
   
   
   Table 4: CFC Request Parameters

   CFC Parameter Type	CFC Parameter Name	Notes
   CGI Header Variable	x_pulse	For CFM pages, if x_pulse CGI header is not present or does not match passed value, abort processing. This prevents unauthorized access to the receiving pages.
   Session Variable	pulse_SX	Client (or Graphcube cloud) will disallow access if no pulse_SX session variable is presented. This prevents unauthorized access to the APP.

   
   
8. The APP CFC Function (myStats) makes only HTTPS CFHTTP calls to the receiving files and the CFC is only available to the Pulse App. The CFC Function (myStats) output is set to false; no data is returned; only the time required to process each CFHTTP calls is returned (See Table 1: Tool Results Data above).
9. For the APP rM.html receiving page, the APP records the time required to retrieve a pre-determined sample 950K-size image file (Figure #4) located in the /pulse/images/ folder.
   
   
   Figure 4: Retrieved Image File

   
   
   
10. The Pulse APP resides on a commercial server at graphcube.com or in the Graphcube cloud. The On-Prem server is a Windows Small Business Server protected by a NETGEAR ProSafe™ Gigabit 8 Port VPN Firewall which restricts all remote access traffic to HTTP (port 80) and HTTPS (Port 443) only.

Enhancements may include automatic notification to email/text accounts when various thresholds in response time are met or exceeded. Initially, it is recommended that after the first week of monitoring, a baseline performance average response for each target is established and then a notification threshold is set whenever the response time is 30% above the baseline for any response factor (CFML, HTML, SQL, Oracle) on any target. The tool can also send automatic results summary reports (Excel) via email on routine schedules (weekly, daily, etc.). These enhancements can be configured with minimal effort and will require clients to provide email/text/report notification lists (see sample Table #5).