9 Security Principles Every Beginner Must Know (Without Googling)

Photo by David Kovalenko on Unsplash

Hey there,

In 2013, I stuttered while explaining the risk to my seniors. I simply assumed that I know how to communicate the risks.

Then, I realised something. If I wanted to grow from a confused to confident cybersecurity engineers, I can’t afford to miss the fundamentals.

If you too are in my spot, that jumps into tools and frameworks but miss the principles behind them, then this post is for you.

And beginners who understand how to best leverage these fundamentals, are going to be the one who:

• Explain risks with clarity.

• Fast-track their growth.

• Take-up high-value tasks.

• Best of all, it make them feel confident in front of senior who expect them to see bigger picture.

In this post, I’ll break down 9 security principles every future security engineers must know so you can design better systems, gain respect from peers, and accelerate your path to becoming an architect.

Let’s dive in.

The 9 Security Principle

Principle #1 - Least Privilege

Most beginners give users or apps more access than needed, thinking it saves time. But this often leads to unnecessary risks and even full system compromise if that account is hacked.

Here’s a simple 3-step way to apply least privilege that we learned in “How to boost GenAI Security with Least Privilege”

1. Identify the exact tasks a user or application needs to perform.

2. Assign only the permissions required for those tasks, nothing extra.

3. Review and adjust access regularly to remove unused or outdated permissions.

It may feel strict at first, but the system remains far safer without added complexity.

By following this principle, you reduce the attack surface and keep your environment resilient against breaches.

---

Principle #2: Defence in Depth

Many people assume a firewall or antivirus alone will protect them. But once that layer is bypassed, attackers have free rein.

Instead of treating control in silos, implement the complete control that we learned.

Here’s a simple 3-step way to apply defence in depth:

1. Layer controls such as firewalls, intrusion detection, and endpoint protection.

2. Add monitoring to detect suspicious activity across multiple layers.

3. Test resilience by simulating attacks to see if one control backs up another.

Firewall + Encryption + Monitoring + Training = Better security

It may sound like extra work, but each layer makes the attacker’s job harder and builds a resilient system that can withstand multiple attack attempts.

---

Principle #3: Secure by Default

Many systems ship with weak or open configurations, expecting users to harden them later. But most people forget to do it, leaving critical gaps.

This puts burden on users who may lack the technical expertise or resources to secure them properly.

Secure by Default is a practice where products are shipped with their security settings already configured to the most secure options, protecting against common exploits without requiring users to make complex changes.

Here’s a simple 3-step way to apply secure by default:

• Use safe defaults like strong passwords, TLS enabled, and least privilege roles.

• Disable unnecessary services or features that aren’t required.

• Document exceptions so changes are intentional, not accidental.

It may feel restrictive at first, but defaults are what protect you when no one is paying attention.

---

Principle #4: Secure by Design

A common mistake is treating security as an afterthought.

This often leads to costly redesigns and missed vulnerabilities. Hence, it is important to build security into systems from the beginning.

There is a wonderful story that is analogous to the way software is built in many organisations.

A group of American car executives who went to Japan to see car assembly line. At the end of the line, the doors were put on hinges the same as in America, but something was missing.

In the end of the line, a worker would take a rubber mallet and tap the edges of the door to ensure that it fits perfectly.

In Japan, that job didn’t seem to exist. Confused, the American executives asked at what point they made sure, the door fits perfectly.

The Japanese guide looked at them, smiled and said -
“We make sure it fits when we design it".

This story is perfect example of how “Secure by Design” works.

In many cases, organisations develop softwares, conduct security assessments and when risk are found, they implement a series short-term patches to mitigate the risk.

Whereas, organisation who understand why the software needs to be Secure by Design:

• Prioritise it.

• Build software with security in mind from the beginning.

• Software inherently become more secure, less vulnerable to attacks and breaches.

They engineer the outcome they want from the beginning.

Here’s a simple 3-step way to build secure by design:

1. Include security during planning and design. Setup Threat Modelling session, Architecture Review discussion and Security Training for Devs.

2. Use secure defaults instead of leaving settings open.

3. Automate checks to catch issues before deployment. Implement tools such as but not limited to:

   1. Static Automated Security Testing(SAST) - Find flaws in coding.

   2. Dynamic Automated Security Testing(DAST) - Find flaws at runtime.

   3. Secret Scanning - Find secret in your code.

   4. Dependency Scanning to prevent Supply Chain Attacks.

It may feel slower at first, but it saves time and money in the long run. Idea is implement one controls, test it, tune it and then move to next.

---

Principle #5: Zero Trust

Many still assume that users and devices inside the network can be trusted.

This blind trust often leads to insider threats or lateral movement by attackers.

Here’s a simple 3-step way to apply zero trust:

1. Verify every request regardless of source. E.g., Add Database Security Groups(firewall), Implement mTLS of internal traffic etc.,

2. Use strong authentication like MFA and device checks.

3. Continuously monitor for changes in behaviour or risk.

Don’t trust anyone by default, even inside the network. Always verify.

---

Principle #6: Separation of Duties

Many small teams let one person do everything — coding, reviewing, and deploying.

Even beginners make this mistake when writing their first IAM policy.

This creates blind spots and increases the chance of unchecked errors.

Here’s a simple 3-step way to apply separation of duties:

1. Assign different roles for development, review, and approval.

2. Enforce policies so no single person controls the full process.

3. Audit regularly to make sure rules are followed.

Split critical tasks between multiple roles.

Implementing this principles, protects against both mistakes and misuse.

---

Principle #7: Fail Securely

Many systems fail in an “open” way — giving access or showing sensitive errors when something breaks. Attackers exploit these weak failure modes easily.

Most common example are:

1. Application Logs displaying stack trace error when fails.

2. SQL dumps revealing tables when fails to process requests.

Here’s a simple 3-step way to fail securely:

1. Hide sensitive details from error messages. Throw generic error.

2. Default to deny access when the system is uncertain.

3. Log failures so they can be analyzed and fixed quickly.

This helps you limit damage when something goes wrong.

---

Principle #8: Keep It Simple (KISS Principle)

The Traditional Tradeoff. Source: actifile.com

Above graph is perfect example of a usability vs security. Keep system complex, no one use it. Keep it too simple and everyone exploits.

A common mistake is over-engineering solutions with too many tools and rules. This complexity creates confusion, gaps, and higher chances of misconfiguration.

Hence, Keeping it Simple is finding the sweet spot between Usability and Security, thus reducing the attack surface.

Here’s a simple 3-step way to keep it simple:

1. Use only what’s needed to meet security goals.

2. Standardize controls instead of adding random tools and funcationlity.

3. Document clearly so everyone knows how things work.

It may seem less impressive, but simple designs are easier to secure and maintain.

It helps you reduce errors and make your security stronger over time.

---

Principle #9: Limiting Blast Radius

I once reviewed an cloud architecture where Dev VPC account was connected to Production VPC account.

Teams keep dev and test environment within same network to make data flow and access easier. When breach happens, they wonder why it happened.

Here’s a simple 3-step way to limit the blast radius:

1. Implement multi-account strategy also known as "The Chinese Wall" advocates for creating dedicated account for Dev/Test Environment and Production for your workload.

2. Implementing Segmentation across Network, application and data.

   1. Setup Private and Public Subnet

   2. Isolate sensitive workload in separate VPC.

   3. Enforce Principle #6.

3. Add Configuration Drift tool such as AWS Config to detect the change.

This helps you add blast radius boundaries, making your infrastructure more resilient.

And there you have it.

The sooner you build this foundation, the faster you'll grow into a skilled cybersecurity engineer.

Chat Soon,

Kushal

What did you think of today’s newsletter?

❤️ Loved it? → Refer it to a friend or drop a ‘Like‘ below.

🥳 Just joined? → Start here: Ultimate Learning Guide for CyberSecurity Beginners.

💡 Have ideas? → Hit reply and tell me how I can make this more useful for you.