Skip to content

Security

Security Defaults

Security access controls extend into your databases. The principle of least privilege needs to be enforced not only for who can connect but also for what they can do within your databases.

For example, until PostgreSQL version 15, PUBLIC (which all users are a member of) could create tables within the public schema unless REVOKE’d. This is just one example.

It’s important to review what the security defaults are for your database product to ensure you are enforcing the least privilege access model where you explicitly grant access to resources.

PostgreSQL 15.0 Release Notes

Stop It!

An interesting article giving yet another example of why you should not use a personal email for work correspondence!

Reputation Risk

Wired recently published a piece on API vulnerabilities in the Points platform used by many hotels, airlines, and banks. One of the researchers pointed out the vulnerabilities would have had “a cascading effect to every company utilizing their loyalty backend”.

“It takes a lifetime to build a good reputation, but you can lose it in a minute.” ~ Will Rogers

AI Prompt Injection Attacks

Bruce Schneier has hit the nail on the head in his recent post on AI prompt injection attacks. Schneier feels it’s not possible to fully secure large language models (LLMs) against this kind of attack. Essentially, you can use AI to generate injection prompts, but read the article to learn more.

Automatically Finding Prompt Injection Attacks

Security Through Obscurity

Another example of why security through obscurity does not work. Radio systems used by police and military outside the US have vulnerabilities that have existed since the 1990s.

The system is also used within “pipelines, railways, the electric grid, mass transit, and freight trains” in many countries, including the U.S.

Do you agree that security through obscurity is not effective?

Code Kept Secret for Years Reveals Its Flaw—a Backdoor