Proxy Usage

Alias Reveal on Response

The VGS alias reveal capability should manifest on the response side. This is recommended as a security measure to keep a customer’s backend interface out of PCI scope. This configuration reduces the communication of sensitive data until the last moment, which significantly reduces the time of alias exposure.

A reveal should not occur on the request side. In such a configuration, sensitive and compliance-scoped data then flows from a VGS proxy to the customer’s backend, leading to potential exposure and unnecessary risk. Therefore, revealing an alias on the request side must only be done when strictly necessary.

Tips on storing HTTP Basic Authentication Secrets Securely

• Do not embed secrets directly in code.

• Do not store secrets in files inside your application, including the application’s source tree.

• If you do accidentally commit secrets to version control, revoke them immediately and generate a new one.

• Ensure secrets do not appear in URLs or anywhere they can be captured in web server logs.

• Never include sensitive data in URL query parameters - Per OWASP guidance, sensitive information (usernames, passwords, tokens, API keys) transmitted in URL query strings can be exposed in multiple locations, including web server logs, browser history, browser cache, and HTTP referer headers, even when using HTTPS.

• Use POST requests instead of GET requests when transmitting sensitive data to avoid query string exposure.

• Review your code carefully and ensure it doesn’t contain secrets or any other private information before publicly releasing it.

• Put the configuration file containing the secrets in the revision control ignore. This prevents committing them by mistake in the future.

• Limit the usage of secrets

• Restrict your secrets to be used by only the IP addresses, referrer URLs, and mobile apps that need them.

• Don't share your secrets with different applications. If more than one application uses the same API, register each application so you get a new set of secrets and update the secrets.

• Delete unneeded secrets.

• Update (Regenerate) your secrets periodically.

References:

Best practices for securely using Secrets

REST Security Cheat Sheet - OWASP

Audit Logs

Audit Logs show a centralized stream of all user activity within an Organization. Part of the security of any organization is to control and monitor access to information. Thus, organization admins need to be able to see the detailed audit trail of all activity that happens.

As of now, VGS Audit Logs can be used to view the latest changes to routes and revert a version to undo certain changes.

Events Types for Audit Logs: VGS Audit Logs capture the following route-specific user activities:

• Route created

• Route updated

• Route reverted

Main Fields for Audit Logs Events

• Date - time when the event happened

• User email - email address of the person who made the change

• Event - the way in which the object was changed

• Event Action Type - created/updated (the way in which the object was changed)

The ‘diff snippet’ shows the snapshot values of two route versions: the previous version, original, and the new one, rewritten. Both versions are shown in a YAML format.

Additional Information in Detail View

• Event

• Event ID

• Date and Time ISO8601

• Resource ID

• User email

• User ID

• User Agent

• Diff Snippet (full YAML configuration)

Revert Version: Each time a user saves a new sandbox/live configuration of a route, VGS automatically creates a new route version and a snapshot. Reverting allows the user to undo a change by reverting the route to some previous version.

Note: Using the revert version feature doesn't delete any changes; it creates a new version that reverts the effects of a specified change.

When doing a revert, you will see a revert event log and “Event ID” that tells you from which event a new version was created.

Data Backups

Data breaches are common. And the threat from ransomware, a type of malware that encrypts your files and holds them hostage for purposes of extortion, is currently rising. There are multiple threats associated with these attacks, including the loss of data, revenue, and reputation.

With ransomware, if your company refuses to pay the ransom, the bad guys often try to increase the pressure by threatening to release your data publicly. This tactic is called “double extortion,” as hackers first exfiltrate a tranche of sensitive data and then threaten to release it. This scenario is even a threat to companies that have backed up their data -- unless it has been properly encrypted or aliased. There are numerous “leak sites” where researchers and journalists regularly read sensitive information stolen by ransomware.

The Importance of Secure Data Backups

Experts say that one of the most important defenses against ransomware is maintaining offline, append-only, encrypted backups of your data. Your backups should be segmented and offline so that criminals cannot access and mutate them; many ransomware variants attempt to find and delete vulnerable backups. Your backups should be encrypted so that if your data is stolen, hackers cannot leverage it for financial fraud or extortion. And all of this must be done on a regular basis in order to make sure that your data is accurate and can be restored without undue delay.

Information security, however, is a complex discipline, and it is a challenge to get everything right. The threat of ransomware means backing up your data must be a critical part of your information security strategy. But in many ways, backups are more challenging to secure than an application. Creating backups tends to increase your security exposure simply by duplicating and disseminating copies of your sensitive data, including proprietary information, personally identifiable information (PII), authentication details, access audits, and much more.

There is a better and more secure way to create data backups by leveraging the power of data aliasing and the VGS Zero Data™ philosophy.

Zero Data™ Threat Mitigation

VGS technology mitigates the threat of ransomware by reducing the spread of sensitive data in your backups. VGS transforms sensitive information into data aliases that, if stolen, are meaningless to data thieves and hackers. Our vault security controls include segregated accounts, key rotation, patch management, audit logging, vulnerability testing, strong encryption, and continuous monitoring, which together cover the vast majority of PCI, SOC 2, GDPR, CCPA, and HIPAA security requirements.

VGS customers are at a dramatically lower risk of data breach and double extortion due to our Zero Data™ approach to information security. Attackers can threaten to release your data, but if it has already been transformed into aliases, the risk of disclosure is minimal, and the criminals have dramatically reduced negotiating power. Even if the attackers do not threaten to release your data, victims must always fear that they have retained copies, which could appear on the dark web at any point in the future.

Because VGS customers do not ever possess copies of the original, sensitive information, corporate data backups are easier and safer to perform. Aliased content allows for novel, real-time, and more concise methods of backup. You can stream and store snapshots of events, such as binlog access requests and responses, with incremental updates. VGS aliases are flexible and can accommodate any storage type, such as stream processing for Apache Kafka. For maximum security, you should also alias all communications related to authentication and authorization so that an attacker cannot access your VGS account.

The facilitation of data backups is only one of the many ways that VGS can improve your information security. Together, we can dramatically reduce the risk and impact of data breaches and ransomware. If you have any questions, please ask.