-
-
-
- CVE-2024-7348
-
- Read Assessment
- Updated: 2024/08/15
-PostgreSQL relation replacement during pg_dump executes arbitrary SQL
- All versions of PostgreSQL, EPAS and PGE prior to 16.4, 15.8, and 14.13
-
-
-Summary:
-Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.
-
-Read More...
- |
-
-
-
- CVE-2024-4317
-
- Read Assessment
- Updated: 2024/05/09
-Restrict visibility of "pg_stats_ext" and "pg_stats_ext_exprs" entries to the table owner
- All versions of PostgreSQL, EPAS and PGE prior to 16.3, 15.7, and 14.12
-
-
-Summary:
-Missing authorization in PostgreSQL built-in views pg_stats_ext and pg_stats_ext_exprs allows an unprivileged database user to read most common values and other statistics from CREATE STATISTICS commands of other users. The most common values may reveal column values the eavesdropper could not otherwise read or results of functions they cannot execute. Installing an unaffected version only fixes fresh PostgreSQL installations, namely those that are created with the initdb utility after installing that version. Current PostgreSQL installations will remain vulnerable until they follow the instructions in the release notes, which are provided as a convenience in the below section. Within major versions 14-16, minor versions before PostgreSQL 16.3, 15.7, and 14.12 are affected. Versions before PostgreSQL 14 are unaffected.
-
-Read More...
- |
-
-
-
- CVE-2024-1597
-
- Read Assessment
- Updated: 2024/03/08
-SQL Injection via line comment generation
- pgJDBC all versions prior to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.28 and EDB pgJDBC all versions prior to 42.5.5
-
-
-Summary:
-pgjdbc, the PostgreSQL JDBC Driver, allows attacker to inject SQL if using PreferQueryMode=SIMPLE. Note this is not the default. In the default mode there is no vulnerability. A placeholder for a numeric value must be immediately preceded by a minus. There must be a second placeholder for a string value after the first placeholder; both must be on the same line. By constructing a matching string payload, the attacker can inject SQL to alter the query,bypassing the protections that parameterized queries bring against SQL Injection attacks. Versions before 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.28 are affected.
-
-Read More...
- |
-
-
-
- CVE-2024-0985
-
- Read Assessment
- Updated: 2024/02/26
-PostgreSQL non-owner REFRESH MATERIALIZED VIEW CONCURRENTLY executes arbitrary SQL
- PostgreSQL, EPAS all versions prior to 15.6.0,14.11.0,13.14.20 and 12.18.23, PGE all versions prior to 15.6.0
-
-
-Summary:
-Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. As part of exploiting this vulnerability, the attacker creates functions that use CREATE RULE to convert the internally-built temporary table to a view. Versions before PostgreSQL 15.6, 14.11, 13.14, and 12.18 are affected. The only known exploit does not work in PostgreSQL 16 and later. For defense in depth, PostgreSQL 16.2 adds the protections that older branches are using to fix their vulnerability.
-
-Read More...
- |
+---
-
\ No newline at end of file
diff --git a/advocacy_docs/security/advisories/cve.mdx.template b/advocacy_docs/security/notifications/advisories/cve.mdx.template
similarity index 100%
rename from advocacy_docs/security/advisories/cve.mdx.template
rename to advocacy_docs/security/notifications/advisories/cve.mdx.template
diff --git a/advocacy_docs/security/advisories/cve20074639.mdx b/advocacy_docs/security/notifications/advisories/cve20074639.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve20074639.mdx
rename to advocacy_docs/security/notifications/advisories/cve20074639.mdx
diff --git a/advocacy_docs/security/advisories/cve201910128.mdx b/advocacy_docs/security/notifications/advisories/cve201910128.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve201910128.mdx
rename to advocacy_docs/security/notifications/advisories/cve201910128.mdx
diff --git a/advocacy_docs/security/advisories/cve202331043.mdx b/advocacy_docs/security/notifications/advisories/cve202331043.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202331043.mdx
rename to advocacy_docs/security/notifications/advisories/cve202331043.mdx
diff --git a/advocacy_docs/security/advisories/cve202341113.mdx b/advocacy_docs/security/notifications/advisories/cve202341113.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341113.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341113.mdx
diff --git a/advocacy_docs/security/advisories/cve202341114.mdx b/advocacy_docs/security/notifications/advisories/cve202341114.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341114.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341114.mdx
diff --git a/advocacy_docs/security/advisories/cve202341115.mdx b/advocacy_docs/security/notifications/advisories/cve202341115.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341115.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341115.mdx
diff --git a/advocacy_docs/security/advisories/cve202341116.mdx b/advocacy_docs/security/notifications/advisories/cve202341116.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341116.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341116.mdx
diff --git a/advocacy_docs/security/advisories/cve202341117.mdx b/advocacy_docs/security/notifications/advisories/cve202341117.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341117.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341117.mdx
diff --git a/advocacy_docs/security/advisories/cve202341118.mdx b/advocacy_docs/security/notifications/advisories/cve202341118.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341118.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341118.mdx
diff --git a/advocacy_docs/security/advisories/cve202341119.mdx b/advocacy_docs/security/notifications/advisories/cve202341119.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341119.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341119.mdx
diff --git a/advocacy_docs/security/advisories/cve202341120.mdx b/advocacy_docs/security/notifications/advisories/cve202341120.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve202341120.mdx
rename to advocacy_docs/security/notifications/advisories/cve202341120.mdx
diff --git a/advocacy_docs/security/advisories/cve20244545.mdx b/advocacy_docs/security/notifications/advisories/cve20244545.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/cve20244545.mdx
rename to advocacy_docs/security/notifications/advisories/cve20244545.mdx
diff --git a/advocacy_docs/security/advisories/index.mdx b/advocacy_docs/security/notifications/advisories/index.mdx
similarity index 100%
rename from advocacy_docs/security/advisories/index.mdx
rename to advocacy_docs/security/notifications/advisories/index.mdx
diff --git a/advocacy_docs/security/advisories/table.template b/advocacy_docs/security/notifications/advisories/table.template
similarity index 100%
rename from advocacy_docs/security/advisories/table.template
rename to advocacy_docs/security/notifications/advisories/table.template
diff --git a/advocacy_docs/security/assessments/cve-2024-0985.mdx b/advocacy_docs/security/notifications/assessments/cve-2024-0985.mdx
similarity index 100%
rename from advocacy_docs/security/assessments/cve-2024-0985.mdx
rename to advocacy_docs/security/notifications/assessments/cve-2024-0985.mdx
diff --git a/advocacy_docs/security/assessments/cve-2024-1597.mdx b/advocacy_docs/security/notifications/assessments/cve-2024-1597.mdx
similarity index 98%
rename from advocacy_docs/security/assessments/cve-2024-1597.mdx
rename to advocacy_docs/security/notifications/assessments/cve-2024-1597.mdx
index b43ccb7e657..d0d764282b1 100644
--- a/advocacy_docs/security/assessments/cve-2024-1597.mdx
+++ b/advocacy_docs/security/notifications/assessments/cve-2024-1597.mdx
@@ -73,7 +73,7 @@ Updated EDB JDBC Drivers are available in EDB Repos in the form of RPM and DEB n
## Related information
-* [pjdbc team's advisory](https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-24rp-q3w6-vc56)
+* [pjdbc team's advisory](https://github.com/pgjdbc/pgjdbc/security/notifications/advisories/GHSA-24rp-q3w6-vc56)
* [EnterpriseDB](https://www.enterprisedb.com/)
* [EDB Blogs link](https://enterprisedb.com/blog/)
diff --git a/advocacy_docs/security/assessments/cve-2024-4317.mdx b/advocacy_docs/security/notifications/assessments/cve-2024-4317.mdx
similarity index 100%
rename from advocacy_docs/security/assessments/cve-2024-4317.mdx
rename to advocacy_docs/security/notifications/assessments/cve-2024-4317.mdx
diff --git a/advocacy_docs/security/assessments/cve-2024-7348.mdx b/advocacy_docs/security/notifications/assessments/cve-2024-7348.mdx
similarity index 100%
rename from advocacy_docs/security/assessments/cve-2024-7348.mdx
rename to advocacy_docs/security/notifications/assessments/cve-2024-7348.mdx
diff --git a/advocacy_docs/security/assessments/index.mdx b/advocacy_docs/security/notifications/assessments/index.mdx
similarity index 100%
rename from advocacy_docs/security/assessments/index.mdx
rename to advocacy_docs/security/notifications/assessments/index.mdx
diff --git a/advocacy_docs/security/notifications/index.mdx b/advocacy_docs/security/notifications/index.mdx
new file mode 100644
index 00000000000..f990617569d
--- /dev/null
+++ b/advocacy_docs/security/notifications/index.mdx
@@ -0,0 +1,121 @@
+---
+WARNING: THIS IS AN AUTOMATICALLY GENERATED FILE - DO NOT MANUALLY EDIT - SEE tools/automation/generators/advisoryindex
+title: EDB Security Notifications
+navTitle: EDB Notifications
+directoryDefaults:
+ iconName: Security
+ indexCards: none
+ hideKBLink: true
+description: A full listing of all security advisories and assessments issued by EDB. It includes details on how to address them, as well as any advisories and fixes released by EDB.
+navigation:
+ - vulnerability-disclosure-policy
+ - advisories
+ - assessments
+---
+
+EDB is committed to a security first approach, from the products we build and the platforms we operate, to the services we provide our customers. Transparency is a core principle for the program and part of this effort includes welcoming incoming reports so that we can address concerns surfaced by our customers or security researchers. You’ll also find it in our advisories, which detail issues found and the required fixes or mitigations needed to keep your data and databases safe.
+
+## Policies
+
+*
+
+
+
+ CVE-2024-7348
+
+ Read Assessment
+ Updated: 2024/08/15
+PostgreSQL relation replacement during pg_dump executes arbitrary SQL
+ All versions of PostgreSQL, EPAS and PGE prior to 16.4, 15.8, and 14.13
+
+
+Summary:
+Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.
+
+Read More...
+ |
+
+
+
+ CVE-2024-4317
+
+ Read Assessment
+ Updated: 2024/05/09
+Restrict visibility of "pg_stats_ext" and "pg_stats_ext_exprs" entries to the table owner
+ All versions of PostgreSQL, EPAS and PGE prior to 16.3, 15.7, and 14.12
+
+
+Summary:
+Missing authorization in PostgreSQL built-in views pg_stats_ext and pg_stats_ext_exprs allows an unprivileged database user to read most common values and other statistics from CREATE STATISTICS commands of other users. The most common values may reveal column values the eavesdropper could not otherwise read or results of functions they cannot execute. Installing an unaffected version only fixes fresh PostgreSQL installations, namely those that are created with the initdb utility after installing that version. Current PostgreSQL installations will remain vulnerable until they follow the instructions in the release notes, which are provided as a convenience in the below section. Within major versions 14-16, minor versions before PostgreSQL 16.3, 15.7, and 14.12 are affected. Versions before PostgreSQL 14 are unaffected.
+
+Read More...
+ |
+
+
+
+ CVE-2024-1597
+
+ Read Assessment
+ Updated: 2024/03/08
+SQL Injection via line comment generation
+ pgJDBC all versions prior to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.28 and EDB pgJDBC all versions prior to 42.5.5
+
+
+Summary:
+pgjdbc, the PostgreSQL JDBC Driver, allows attacker to inject SQL if using PreferQueryMode=SIMPLE. Note this is not the default. In the default mode there is no vulnerability. A placeholder for a numeric value must be immediately preceded by a minus. There must be a second placeholder for a string value after the first placeholder; both must be on the same line. By constructing a matching string payload, the attacker can inject SQL to alter the query,bypassing the protections that parameterized queries bring against SQL Injection attacks. Versions before 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.28 are affected.
+
+Read More...
+ |
+
+
+
+ CVE-2024-0985
+
+ Read Assessment
+ Updated: 2024/02/26
+PostgreSQL non-owner REFRESH MATERIALIZED VIEW CONCURRENTLY executes arbitrary SQL
+ PostgreSQL, EPAS all versions prior to 15.6.0,14.11.0,13.14.20 and 12.18.23, PGE all versions prior to 15.6.0
+
+
+Summary:
+Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. As part of exploiting this vulnerability, the attacker creates functions that use CREATE RULE to convert the internally-built temporary table to a view. Versions before PostgreSQL 15.6, 14.11, 13.14, and 12.18 are affected. The only known exploit does not work in PostgreSQL 16 and later. For defense in depth, PostgreSQL 16.2 adds the protections that older branches are using to fix their vulnerability.
+
+Read More...
+ |
+
+
\ No newline at end of file
diff --git a/advocacy_docs/security/templates/advisoriesindex.njs b/advocacy_docs/security/notifications/templates/advisoriesindex.njs
similarity index 100%
rename from advocacy_docs/security/templates/advisoriesindex.njs
rename to advocacy_docs/security/notifications/templates/advisoriesindex.njs
diff --git a/advocacy_docs/security/templates/assessmentsindex.njs b/advocacy_docs/security/notifications/templates/assessmentsindex.njs
similarity index 100%
rename from advocacy_docs/security/templates/assessmentsindex.njs
rename to advocacy_docs/security/notifications/templates/assessmentsindex.njs
diff --git a/advocacy_docs/security/templates/securityindex.njs b/advocacy_docs/security/notifications/templates/securityindex.njs
similarity index 100%
rename from advocacy_docs/security/templates/securityindex.njs
rename to advocacy_docs/security/notifications/templates/securityindex.njs
diff --git a/advocacy_docs/security/vulnerability-disclosure-policy.mdx b/advocacy_docs/security/notifications/vulnerability-disclosure-policy.mdx
similarity index 100%
rename from advocacy_docs/security/vulnerability-disclosure-policy.mdx
rename to advocacy_docs/security/notifications/vulnerability-disclosure-policy.mdx
diff --git a/advocacy_docs/security/securing-epas/TDE/index.mdx b/advocacy_docs/security/securing-epas/TDE/index.mdx
new file mode 100644
index 00000000000..fa3959c03b6
--- /dev/null
+++ b/advocacy_docs/security/securing-epas/TDE/index.mdx
@@ -0,0 +1,8 @@
+---
+title: Transparent Data Encryption for Postgres
+navTitle: TDE
+description: Transparent Data Encryption (TDE) is a technology that encrypts data at rest. This guide provides an overview of TDE and how to implement it in PostgreSQL.
+---
+
+TBD
+
diff --git a/advocacy_docs/security/securing-epas/index.mdx b/advocacy_docs/security/securing-epas/index.mdx
new file mode 100644
index 00000000000..35e0ac12555
--- /dev/null
+++ b/advocacy_docs/security/securing-epas/index.mdx
@@ -0,0 +1,8 @@
+---
+title: Securing EDB Postgres Advanced Server
+navTitle: Securing EPAS
+description: This section provides a comprehensive guide on how to secure your EDB Postgres Advanced Server database. Building on the PostgreSQL guides, it covers features that are unique to EPAS.
+---
+
+TBD
+
diff --git a/advocacy_docs/security/securing-pgd/index.mdx b/advocacy_docs/security/securing-pgd/index.mdx
new file mode 100644
index 00000000000..a01fe0fc1e2
--- /dev/null
+++ b/advocacy_docs/security/securing-pgd/index.mdx
@@ -0,0 +1,8 @@
+---
+title: Securing EDB Postgres Distributed
+navTitle: Securing PGD
+description: Containing, a full explanation on why and how to secure your EDB Postgres Distributed clusters and the needs of a distributed database. Building on the PostgreSQL and EPAS security guides, this section covers the unique security considerations for distributed databases.
+---
+
+TBD
+
diff --git a/advocacy_docs/security/securing-postgresql/101/index.mdx b/advocacy_docs/security/securing-postgresql/101/index.mdx
new file mode 100644
index 00000000000..e47cc46173a
--- /dev/null
+++ b/advocacy_docs/security/securing-postgresql/101/index.mdx
@@ -0,0 +1,142 @@
+---
+title: Securing PostgreSQL 101
+navTitle: Security 101
+description: The essentials of PostgreSQL security for those new to securing their database.
+---
+
+The following are basic practices for securing your PostgreSQL installation.
+
+## Install the latest version
+
+- **Always use the most recent version.** Regularly update PostgreSQL to the latest stable release. For EDB releases, see the [EDB repositories](https://www.enterprisedb.com/repos-downloads).
+
+- **Apply security patches.** Ensure security patches are applied promptly. For EDB security vulnerabilities and advisories, see the [EDB Vulnerability disclosure policy](/security/notifications/vulnerability-disclosure-policy/).
+
+## Use strong authentication methods
+
+PostgreSQL supports several authentication methods. Always use the most secure option available.
+
+- **Password authentication.** Ensure that all users authenticate with strong passwords. Because it provides stronger hashing, use `scram-sha-256` for password hashing instead of `md5`.
+
+- **LDAP/Kerberos/SSO.** Integrate centralized authentication systems like LDAP, Kerberos, or single sign-on (SSO) for enhanced security.
+
+## Limit access with pg_hba.conf
+
+PostgreSQL’s host-based access control file (`pg_hba.conf`) is your first line of defense for controlling who can connect to the database. To ensure security:
+
+- **Restrict host connections.** Allow only trusted hosts.
+
+- **Use CIDR notation.** Limit access to specific IP ranges in `pg_hba.conf`. Example:
+
+```bash
+host all all 192.168.1.0/24 scram-sha-256
+```
+- **Use local method.** For connections from the same machine, use Unix domain sockets with peer authentication, limiting connections to system users.
+
+## Enforce SSL/TLS connections
+
+Encrypt traffic between the client and PostgreSQL server using SSL. This practice can prevent sensitive data (like passwords and query results) from being intercepted.
+
+- **Enable SSL.** Ensure that `ssl = on` in `postgresql.conf`.
+
+- **Use valid SSL certificates.** Use certificates for secure communication (self-signed or CA-signed).
+
+- **Force SSL.** Ensure all connections use SSL via `pg_hba.conf`. Example:
+
+```bash
+hostssl all all 0.0.0.0/0 scram-sha-256
+```
+
+## Use role-based access control (RBAC)
+
+PostgreSQL implements a robust role-based access control system. Some key practices include:
+
+- **Principle of least privilege.** Grant roles the minimum permissions necessary.
+
+- **Separate roles for users/applications.** Avoid using superuser accounts or the default postgres role for daily operations.
+
+- **Use GRANT/REVOKE.** Assign specific privileges to roles. Example:
+
+```sql
+GRANT SELECT, INSERT ON my_table TO my_user;
+```
+
+## Use encrypted passwords
+
+Make sure that passwords are stored using secure hashing methods (scram-sha-256 in modern PostgreSQL versions).
+
+- **Enable scram-sha-256.** Configure PostgreSQL to store passwords securely by setting `password_encryption = 'scram-sha-256'` in your `postgresql.conf` file:
+
+```bash
+password_encryption = 'scram-sha-256'
+```
+
+## Audit and monitor database activity
+
+Enable logging and auditing to keep track of database activity.
+
+- **Enable logging.** Log all user connections and queries.
+
+- **Track role changes.** Regularly audit role modifications and permissions to detect unauthorized changes.
+
+- **Use pgAudit.** Third-party tools like pgAudit can enable detailed audit logging.
+
+- **Enable connection and query logs.** Capture login attempts, successful connections, and queries executed using settings in `postgresql.conf`:
+
+```bash
+log_connections = on
+log_disconnections = on
+log_statement = 'all'
+```
+
+## Regular backups and secure backup storage
+
+Backups are crucial, but they must also be secured. Be sure to:
+
+- **Use encrypted backups.** Encrypt database backups to reduce the chance of unauthorized access.
+
+- **Restrict backup access.** Allow only authorized personnel to access, view, or restore backups.
+
+- **Test restores.** Regularly test backups to ensure they're complete and can be restored properly without any data integrity issues.
+
+## Disable unnecessary features
+
+Reduce your attack surface by disabling unused features:
+
+- **Remove unused extensions.** Disable any extensions that aren't actively used.
+
+- **Disable trust authentication.** Ensure `trust` authentication isn't used in production as it allows users to log in without a password.
+
+- **Disable untrusted languages.** Prevent the use of languages that allow arbitrary code execution, such as PL/Python.
+
+## Vulnerability scanning and penetration testing
+
+- **Regularly scan for vulnerabilities.** Use security scanners to find vulnerabilities.
+
+- **Penetration resting.** Test the security of your PostgreSQL instance. You may need to hire security professionals to test your database security periodically.
+
+## Network security controls
+
+Strengthen PostgreSQL’s security by securing the network it operates in.
+
+- **Set firewall rules.** Restrict database access to necessary ports.
+
+- **Limit network exposure.** Use VPNs or internal networks for database access. Avoid exposing PostgreSQL directly to the internet.
+
+- **Use intrusion detection.** Use IDS tools to monitor for suspicious activity.
+
+## Regularly review user permissions
+
+- **Develop a review cadence.** Regularly review user and role permissions to ensure no unnecessary privileges were granted.
+
+- **Remove unnecessary privileges.** Periodically review and revoke unnecessary privileges. Remove access immediately when a user no longer needs it.
+
+## Secure OS and file permissions
+
+PostgreSQL runs on an operating system that also needs to be secured.
+
+- **Restrict file access.** Ensure that only the PostgreSQL service user can access critical files such as the data directory and logs. Set restrictive permissions (700) on the data directory.
+
+- **Harden the OS.** Apply operating system hardening practices, including disabling unnecessary services and ensuring regular OS updates.
+
+
diff --git a/advocacy_docs/security/securing-postgresql/201/index.mdx b/advocacy_docs/security/securing-postgresql/201/index.mdx
new file mode 100644
index 00000000000..623341ac2dd
--- /dev/null
+++ b/advocacy_docs/security/securing-postgresql/201/index.mdx
@@ -0,0 +1,166 @@
+---
+title: Securing PostgreSQL 201
+navTitle: Security 201
+description: Building on the basics, this guide covers more advanced topics in PostgreSQL security.
+---
+
+After you've mastered the basics of securing your PostgreSQL database, you can dive deeper into intermediate topics.
+
+These intermediate security techniques help to further safeguard your data, improve auditability, and reduce risks associated with more sophisticated attacks. By focusing on enhanced role management, encryption, fine-grained access control, auditing, and cloud-specific configurations, you can build a robust defense for your databases.
+
+Keep evolving your security posture by staying updated on emerging threats and security features in new PostgreSQL releases.
+
+## Advanced role management and privileges
+
+Effective management of roles and privileges is essential for maintaining a secure PostgreSQL environment.
+
+- **Avoid using superuser roles.** Limit superuser privileges to only the most essential operations. Always create distinct, minimally privileged roles for day-to-day database tasks.
+
+- **Create custom roles.** Create task-specific roles for finer privilege management. Rather than using a single, all-encompassing role, create custom roles for different functions like read-only, read-write, and admin tasks. This practice limits the scope of potential security breaches. For example:
+
+```sql
+CREATE ROLE read_only NOINHERIT;
+GRANT SELECT ON ALL TABLES IN SCHEMA public TO read_only;
+```
+
+- **Establish role inheritance.** Use role inheritance to streamline privilege assignments and create hierarchies of roles that simplify privilege management. A parent role can be granted a specific set of privileges, which can then be inherited by child roles:
+
+```sql
+CREATE ROLE base_role;
+CREATE ROLE admin_role INHERIT base_role;
+```
+
+- **Revoke public privileges.** Remove default permissions from the public role. By default, new databases and tables grant certain privileges to the public role. Best practice is to revoke these:
+
+```sql
+REVOKE ALL ON DATABASE mydb FROM PUBLIC;
+REVOKE ALL ON SCHEMA public FROM PUBLIC;
+```
+
+## Fine-grained access control with row-level security
+
+- **Enable row-level security.** Row-level security (RLS) provides fine-grained control over who can access specific rows in a table. This type of security is essential when different users need access to different subsets of data.
+
+ Enforce RLS policies on sensitive tables. To activate RLS for a table, you first need to enable it:
+
+```sql
+ALTER TABLE employees ENABLE ROW LEVEL SECURITY;
+```
+
+- **Define security policies.** Once RLS is enabled, you can create policies to specify which users can access or modify rows in the table. For example:
+
+```sql
+CREATE POLICY employee_policy ON employees
+FOR SELECT
+USING (employee_id = current_user);
+```
+
+### Database encryption
+
+Encryption is critical for protecting data at rest and in transit. Intermediate PostgreSQL setups often leverage encryption to secure sensitive information.
+
+- **Encrypt sensitive columns.** Use pgcrypto to encrypt sensitive data at the column level. While PostgreSQL doesn’t natively support column-level encryption,
+you can use client-side encryption libraries such as pgcrypto to encrypt and decrypt data. For example:
+
+```sql
+SELECT pgp_sym_encrypt('secret data', 'encryption key');
+```
+ Ensure that encryption keys are stored securely outside the database, such as in AWS KMS, HashiCorp Vault, or other secure key management systems.
+
+- **Use full disk encryption.** If column-level encryption isn't feasible, use full-disk encryption to secure the data directory. Encrypting the entire disk ensures that sensitive data is protected in the event of unauthorized physical access to the database server.
+
+## pg_hba.conf advanced configurations
+
+The `pg_hba.conf` file controls access to PostgreSQL at the network level. Intermediate configurations involve more complex filtering and control mechanisms.
+
+- **Set granular network restrictions.** Configure specific IP ranges or hosts for different roles. Define access based on user, database, or IP address to create fine-grained network policies. For example, restrict administrative access to a specific IP range:
+
+```bash
+host all postgres 10.0.0.0/8 scram-sha-256
+```
+
+- **Separate roles by network.** Allow different roles based on their origin IP. You can create roles that have different levels of access based on their network of origin. For instance, you can create read-only users on a public network and read-write users on a private network:
+
+```bash
+host all read_only_user 0.0.0.0/0 scram-sha-256
+host all read_write_user 10.0.0.0/8 scram-sha-256
+```
+
+## Database auditing and logging
+
+Auditing is essential for identifying abnormal behavior and unauthorized access. It also helps in compliance with security standards like PCI-DSS and GDPR.
+
+- **Enable pgaudit.** Use pgaudit for detailed logging of database activity. This extension provides detailed logging of SQL statements at various levels (DDL, DML, and more). To install and configure it:
+
+```sql
+CREATE EXTENSION pgaudit;
+```
+
+ To configure pgaudit to log SELECT statements:
+
+```bash
+pgaudit.log = 'read'
+```
+
+- **Configure fine-grained logging.** Customize logging configurations to capture DDL, DML, and more. PostgreSQL offers several levels of logging, but for performance reasons, fine-tune it.
+Enable specific logging for failed login attempts or DDL changes:
+
+```bash
+log_connections = on
+log_disconnections = on
+log_statement = 'ddl'
+```
+
+For more information on pgAudit, see the [pgAudit documentation](https://www.pgaudit.org).
+
+## Monitoring and alerting
+
+Intermediate PostgreSQL security requires robust monitoring and alerting. Several tools and configurations can help with this:
+
+- **PostgreSQL monitoring tools.** Tools like pg_stat_statements, pgBadger, or third-party tools such as Prometheus and Grafana, provide insights into database activity and performance metrics.
+
+- **CloudWatch for AWS Aurora.** For AWS Aurora PostgreSQL users, leverage CloudWatch to monitor database performance metrics and set up alarms for unusual patterns in CPU, memory, or I/O usage.
+
+- **Alerts for suspicious activity.** Configure alerts for specific actions and abnormal behaviors, such as multiple failed login attempts, database role changes, or connections from unknown IP addresses. For example:
+
+```bash
+log_min_error_statement = 'ERROR'
+log_min_duration_statement = 1000
+```
+
+## Database hardening
+
+Hardening your PostgreSQL server is an intermediate security practice that reduces the attack surface by removing or disabling unnecessary features.
+
+- **Remove unused extensions.** Extensions can increase the attack surface of PostgreSQL. Disable or remove any extensions you don't actively use. For example:
+
+```sql
+DROP EXTENSION IF EXISTS plperl;
+```
+
+- **Lock down data directory.** Ensure that the PostgreSQL data directory is accessible only by the PostgreSQL user. Use file system permissions (chmod 700) to lock down access:
+
+```bash
+chmod 700 /var/lib/postgresql/data
+```
+
+## Securing PostgreSQL on cloud providers
+
+Cloud environments introduce additional layers of complexity. The following can help secure your PostgreSQL instances in the cloud:
+
+- **AWS RDS encryption.** Use AWS RDS's built-in encryption for data at rest with KMS-managed keys. You can easily enable it while creating an RDS instance.
+
+- **Network access restrictions.** Use cloud-level security groups or firewalls to restrict access to the PostgreSQL instance. Allow only trusted IPs or VPCs to connect to the database.
+
+- **IAM authentication.** Use AWS IAM roles and policies to manage access to PostgreSQL instances. IAM authentication provides an extra layer of security, reducing the need for password management:
+
+```bash
+aws rds generate-db-auth-token --hostname 
+