SQLi

CashApp, Zelle, Venmo, ApplePay, Square – the payments industry is growing and expanding into areas we hadn’t imagined. Everyone relied on it before the pandemic – now it’s critical infrastructure and embedded into our everyday habits.

For payments providers, how are you protecting your payments application and databases?

Applications store their data in a database in order to efficiently retrieve and make use of it. A database may contain everything from configuration data, usernames and passwords, to critical information such as results of your last medical examination. Some databases know you owe money and to whom, what you posted on a social media app two years ago, what you typically order for lunch and much more. Needless to say, this is a treasure trove for thieves, and a huge target. All this data is shared under the assumption that the application creator is doing everything possible to protect our most personal information. The tools exist to address it. So…… “how are the bad guys getting access to our data?”

One of the most common database attacks, and interestingly enough, one of the simplest to protect against, is SQL injection (SQLi).

This attack is where malicious SQL statements are inserted into an entry field for execution. A successful SQLi attack can read sensitive data such as usernames, passwords, credit card numbers (and more), tamper and destroy data, execute administrative operations, and worse.

Below is an example of SQL Injection.

This form accepts a username and password as input, validates the entry in a table called users and, if both username and password match, grants the user access.

There is no guarantee that a user will only enter a valid username in the username field. In the above example, a user has entered the partial SQL statement ‘or ‘1’ – ‘1 and a blank password. The SQL engine interprets the command literally and since 1 will ALWAYS equal 1, grants the malicious user access to the application without a valid username or password.

Layering security strategies provides comprehensive protection against this type of common attack.

Step 1 – Sanitize all input, then escape all input. Easy stuff, right? This should also be coupled with proper database permissions and always use prepared statements or parameterized queries whenever user input is required. Parameterized queries are the database engine’s natural defense against SQLi. Whitelist Maps are also an effective strategy to protect against SQLi in cases where escaping and parameterization doesn’t help. If you’re interested in this topic, there are tons of great resources on the www.owasp.org website that describe an overall SQLi protection strategy.

Secure, NonStop SQL Database Management

SQLXPress from XYPRO is the most secure and functional database management solution for NonStop SQL. Think about it as the Microsoft SQL Management Studio for NonStop. SQLXPress includes a comprehensive set of security controls, including:

• Multi-factor Authentication
• Auditing
• Access Control
• Session Encryption
• Code Integrity
• SQL Injection Protection

Multi-factor Authentication

The SQLXPress client supports multi-factor authentication (MFA), a PCI-DSS and GDPR requirement, by prompting users for a second factor. Used in conjunction with XYGATE User Authentication (XUA), which is provided on each HPE NonStop server, you’re up-to-date not only with the very latest in PCI 3.2.1 (and soon 4.0) MFA compliance requirements but also with the advice of every security expert out there. Multi-factor authentication is a must!

Auditing

Configure the level of audit data that is collected by the audit subsystem. The audit subsystem records the actions of SQLXPress users and contains detailed information, including date and time, user logon name, PC device identification, SQL statement text, SQL parameter values, outcome details, and much more.

Audit trail data is integrated with analytics solutions like SPLUNK through XYGATE Merged Audit. A rich set of audit reports is available, from activity summary reports down to individual actions. Reports are filtered by time of day, user, device, and SQL object name.

Audit data answers questions such as:

• Who accessed or changed data?
• When was it changed?
• From which device was it changed?
• Who tried to perform an unauthorized command?

Audit data is integral to effective troubleshooting. Provide diagnostic information to other departments or grant audit report access to authorized users on an individual, audited basis.

Every HPE NonStop system is delivered with XYGATE Merged Audit (XMA). Additionally, an XMA plugin integrates the SQLXPress audit data directly into the XMA database, enabling sophisticated audit reporting and alerting capabilities for all NonStop SQL activity. Now just deliver that audit data to your enterprise SIEM such as SPLUNK or QRADAR, integrating NonStop database security into your overall enterprise security program

Access Control

NonStop SQL supports access control “out of the box”. SQLXPress augments these standard access control features by providing a more granular level of control over the actions users are permitted to perform, and the SQL objects they are permitted to access from within SQLXPress.

Role-based Access Control

Like all XYGATE software, SQLXPress supports a role-based access control model:

• Roles are granted permissions to perform activities
• Users are assigned to roles
• Roles may be restricted to an “environment” (an environment is a collection of specific SQL objects)
• Authorization checks on access & activity requests

Access control is configured to suit the needs of the organization.

Separation of Duties

The Security Administrator is responsible for the configuration and management of the SQLXPress security subsystem, including audit and access control via a familiar user interface.

To really appreciate SQLXPress access control let’s look at some use cases:

Use Case 1: Command Lockdown

NonStop SQL permits the owner of an SQL object, like a table, or a view, to perform any DDL or utility operation on the object. SQLXPress access control refines this so that restrictions can be applied to individual operations.

Many commands, like Update Statistics, or Split Partition, are performed as part of the routine duties of a DBA. The DBA should have permission to perform them on an ongoing basis.

However, there are some operations like Purge Data, Drop Table, or Disable Trigger, that are not required for the normal operation of the database, and can have disastrous consequences if performed inadvertently. SQLXPress access control allows these potentially dangerous commands to be “locked down” during normal use. When the DBA needs to perform a locked-down command, the Security Administrator temporarily grants permission for the command. When the command has been completed, the security administrator revokes permission.

Use Case 2: Data Access Restrictions

NonStop SQL permits the owner of a table to view and change the data stored in the table. SQLXPress access control can be used to limit the owner’s access to data while still permitting the owner to manage the table.

SQLXPress security controls mean the owner can be prevented from changing data and can even be prevented from viewing data at all.

Use Case 3: Database Visibility Restrictions

SQL metadata is a rich source of information about the databases on the system. It includes details on table names, column names, security settings, data validation rules, and much more. Most organizations will want to limit access to SQL metadata to authorized users only.

However, with NonStop SQL/MX, SQL metadata is secured for public read access. This means that any SQL/MX user can view information about all the databases on the system. In SQL/MP, metadata is secured per catalog.

To enable database visibility restrictions, the SQLXPress access control feature allows the Security Administrator to define one or more “environments” on a system. An environment provides a restricted view of the SQL objects on a system. Only objects that have been registered in an environment are made visible to the user.

The Security Administrator can restrict the SQL objects that are made visible to a user by assigning him a role for an environment. The user must open an environment to use SQLXPress and can only work with the SQL objects that are registered in that environment.

Furthermore, a user can be granted roles for more than one environment, and even granted a different role in each of those environments. For example, user DEV.JOHN can be granted the role of Senior DBA in the DEV_ATM environment, and the role “Guest” in the QA_ATM environment.

Summary

With the most comprehensive set of features and full support of both NonStop SQL/MX and SQL/MP, SQLXPress is the leading solution for managing NonStop SQL databases.

HPE NonStop SQL databases store highly sensitive and private information. In an increasingly security-conscious world, customers expect their database engines and database management tools to provide comprehensive security–and SQLXPress delivers.