In the world of software engineering, we often focus on building things that work. But true resilience lies in designing systems that know how to fail safely. The internet is built on the assumption that components will inevitably break—databases will go offline, networks will drop packets, and servers will crash.

For a security architect, the question is not if your system will fail, but how it will fail. The answer must be: it must Fail Securely.

What is the “Fail Securely” Principle?

The principle of “Fail Securely” (or Fail Closed) dictates that in the event of an unexpected error, component failure, or system malfunction, the system should default to the most secure, restrictive state possible.

This usually means prioritizing Confidentiality and Integrity over Availability.

The Two Modes of Failure

To understand Fail Securely, you must contrast it with the dangerous alternative:

1. Fail Open (Insecure): The system defaults to allowing maximum access or functionality. If the security mechanism fails (e.g., the firewall dies, or the authentication service crashes), the system assumes everything is fine and lets everyone in. This maximizes availability but completely eliminates security.
2. Fail Securely (Fail Closed): The system defaults to blocking all access or functionality until the security mechanism is restored and can verify the legitimacy of the request. This sacrifices availability during the failure but guarantees that unauthorized access cannot occur.

The Rule: If a security check cannot be performed successfully, the action being requested must be denied.

Application Example: The Authentication Database Disconnect

Consider a modern web application with a secure login endpoint that relies on a central database to verify user credentials and roles.

Scenario: The Database Goes Offline

The application server loses its connection to the database where all user passwords and permissions are stored.

In the Fail Securely application, the application prefers to inconvenience the user rather than compromise the integrity or confidentiality of its data. Once the database connection is restored, authentication resumes seamlessly.

Why This Principle is Critical for Modern Systems

1. Zero Trust Compliance

The “Fail Securely” principle is a cornerstone of Zero Trust architecture. If a service cannot verify the identity, context, or integrity of a request (i.e., it can’t trust it), the default action is always Deny.

2. Protecting Sensitive Data

In complex systems involving Role-Based Access Control (RBAC), losing the authorization component is catastrophic. If the system cannot determine if a user is an

or a

, falling back to

privileges (Fail Open) would expose all sensitive data. Failing securely ensures the user gets zero access until their role is confirmed.

3. Mitigating Denial of Service (DoS) Attacks

While a DoS aims to reduce availability, a sophisticated attacker might attempt to crash a security service (like a firewall or authorization microservice) and then rely on the system to “Fail Open” to gain unauthorized entry. Designing the system to Fail Securely removes this attack vector entirely.

By embedding the Fail Securely mindset into every component—from input validation routines to network configuration—we build software that is inherently more resilient and trustworthy, even when the inevitable chaos of system failure occurs.

In the world of cybersecurity, there’s a common paradox: the biggest threats aren’t zero-day exploits (flaws no one knows about), but known vulnerabilities for which a fix has been available for months.

This is the failure of Patch Management — the systematic process of identifying, testing, and deploying updates to all your systems and software. It’s often viewed as a mundane IT task, but in reality, it is the single most critical defense against modern cyberattacks.

Here’s what a truly robust patch management strategy looks like, and why neglecting it is an existential risk.

The Five Pillars of a Robust Patch Management Strategy

Patching isn’t just about clicking “update.” A professional strategy is a disciplined, cyclical process that minimizes risk while preserving business functionality.

1. Inventory and Discovery

You can’t fix what you can’t see. The first step is maintaining a meticulous inventory of all IT assets—hardware, operating systems, and every single third-party application and library, including version numbers. A robust strategy relies on a secure Configuration Baseline to know what a “healthy” system looks like, making it easier to spot outdated software.

2. Assess and Prioritize

Not every patch is equally urgent. Teams must triage the incoming flood of updates based on two factors:

• Severity: How critical is the vulnerability’s score (CVSS)? Actively exploited flaws (zero-days or highly publicized threats) jump to the top of the queue.
• Impact: Does the vulnerability affect a mission-critical, public-facing system? Patches for these systems get deployed before those for non-critical internal tools.

3. Test and Validate (The Non-Negotiable Step)

Many system failures are caused by patches that conflict with existing business applications. A robust strategy never deploys a patch directly to production.

• Sandboxing: Patches are first applied to a staging or QA environment that perfectly mirrors the production environment.
• Regression Testing: Standard operational workflows are run to ensure the patch doesn’t introduce new bugs or break existing functionality. Skipping this step is tempting but often leads to costly downtime.

4. Deploy and Verify

Deployment should be systematic and automated. For large organizations, this means using a Phased Rollout or Ring Deployment strategy—patching a small, non-critical group first, then a larger group, and finally the most critical assets. After deployment, specialized tools must verify that the patch was successfully applied and that the system reports the correct, updated version number.

5. Audit and Review

The final step is critical for compliance and internal knowledge. Patches must be monitored for unexpected side effects. Detailed records of successful and failed deployments must be kept, creating an Audit Trail that proves due diligence—a requirement for most compliance regimes.

The Existential Risks of Patch Management Failure

When the patch process breaks down, the risks escalate rapidly from minor inconvenience to catastrophic breach.

1. Guaranteed Security Breaches

This is the single biggest consequence. Most successful cyberattacks, including major ransomware incidents like WannaCry, exploit vulnerabilities that had been patched months or even years earlier. When a vendor releases a patch, they also effectively publish the blueprint for the attack. If you don’t apply the fix promptly, you leave a literal open door for automated scanners and attackers looking for an easy target.

2. Regulatory Fines and Compliance Nightmares

Failure to patch is a direct violation of several major compliance standards.

• PCI DSS (Payment Card Industry Data Security Standard) requires timely patching.
• HIPAA (Health Insurance Portability and Accountability Act) requires protecting patient data.

Failure to demonstrate a comprehensive patching history during an audit can result in multi-million dollar fines and public relations damage, far exceeding the cost of the actual patching process.

3. Crippling System Instability

Delaying patches often leads to dependency conflicts. When you finally try to apply multiple cumulative updates months later, the changes may conflict with new applications, custom code, or underlying OS files, causing crashes, instability, or even system-wide downtime. Furthermore, running outdated software means vendors may refuse to offer technical support, leaving your internal IT team to struggle with complex problems alone.

4. Expansion of the Attack Surface

Every unpatched component—from a minor third-party JavaScript library (OWASP A06: Vulnerable Components) to an outdated server OS—is an entry point. Once an attacker compromises one of these vulnerable systems, they use it as a foothold to spread the attack through Lateral Movement across your entire network.

By treating patch management as a disciplined, business-critical process rather than a sporadic IT chore, organizations dramatically reduce their attack surface and protect their core business functions.

If you’re building software today, your security strategy must start with the OWASP Top 10.

More than just a list of flaws, this document—published by the non-profit Open Web Application Security Project (OWASP)—is the industry-standard consensus on the most critical security risks facing modern web applications. It’s the foundational blueprint that dictates where security resources are spent, how developers are trained, and how applications are tested.

Here is a breakdown of the vital role the OWASP Top 10 plays across the entire lifecycle of application development and security assurance.

1. Role in Secure Development (Shifting Left)

The most effective security is proactive. The Top 10 helps organizations achieve “Shift Left” security, meaning risks are addressed in the design and coding stages, long before deployment.

Guiding Design and Requirements

When a feature is designed, the Top 10 acts as a checklist to prevent systemic failure. A team conducting Threat Modeling (a technique to identify threats early in the lifecycle) will use the list as a prompt. For example, they’ll ask: “If we implement this user profile feature, what steps must we take to prevent Broken Access Control (A01)?”. This ensures security requirements are baked into the architecture, not bolted on as an afterthought.

Setting Secure Coding Standards

For developers, the list translates directly into mandatory coding practices:

• Injection (A03): Always use parameterized queries for database access.
• Cryptographic Failures (A02): Always use slow, modern hashing algorithms (like Argon2) for storing passwords.
• Insecure Design (A04): Requires developers to rely on security frameworks and vetted patterns rather than rolling their own, potentially insecure, logic.

By training teams on these 10 categories, companies ensure the most common and damaging flaws are prevented at the source.

2. Role in Security Testing and Assurance

Once the code is written, the OWASP Top 10 becomes the primary guide for verification and validation efforts. It tells security teams exactly what to look for and how to look for it.

Structuring Penetration Testing

A formal Penetration Test is rarely a random hunt for bugs; it’s a structured exercise. The Top 10 defines the scope and methodology for these tests. Testers methodically attempt to exploit vulnerabilities in each category—checking everything from session handling to error messages.

For example, a penetration tester will spend significant time confirming:

• Permissions are correctly validated on the server (testing A01).
• The application does not reveal internal system details via verbose error logging (testing A05 Security Misconfiguration).
• API endpoints cannot be tricked into calling internal network resources (A10 Server-Side Request Forgery).

Directing Automated Security Tools

Automated security scanners use the OWASP Top 10 as their core dictionary:

• SAST (Static Application Security Testing): These tools scan source code without executing it. They are programmed to flag code patterns that lead to risks like A06 (Vulnerable Components) by checking dependency versions, or to find insecure cryptographic functions.
• DAST (Dynamic Application Security Testing): These tools test the live, running application by actively sending malicious inputs. They specifically target flaws like Injection (A03) and Identification and Authentication Failures (A07) to verify that defensive coding is working in practice.

Communicating Risk

Finally, the Top 10 provides a universal language for risk reporting. When a vulnerability is found, classifying it as A09: Security Logging and Monitoring Failures immediately communicates the severity and scope of the flaw to developers, managers, and compliance teams, accelerating the remediation process.

Conclusion: The Non-Negotiable Baseline

The OWASP Top 10 is far more than a cautionary list; it is the non-negotiable security baseline for any organization building or maintaining web applications. Its role spans from the initial security design documentation to the final penetration test report, ensuring that teams focus on preventing the known threats that cause the most damage. If you can successfully mitigate the Top 10, you have built a robust and defensible application.

Does this give you a clearer picture of how essential this document is across the security ecosystem?

If you’ve ever signed up for a new app using “Log in with Google” or “Connect with Spotify,” you’ve used OAuth 2.0. This protocol is the backbone of modern delegated access, but its terminology can sometimes feel like alphabet soup.

To truly understand how OAuth works, you just need to focus on two main actors and their responsibilities: the Client (the app that wants access) and the Authorization Server (the trusted gatekeeper).

The Client: The Requesting Party

In the context of OAuth 2.0, the Client is simply the application, website, or service that needs to access a user’s data or functionality on another platform.

Think of the Client as a hotel guest who needs access to a specific room (the user’s protected data). The guest doesn’t own the room, but they need temporary, defined access.

Key Roles of the Client:

1. Initiates the Flow: The Client starts the entire process by sending the user to the Authorization Server. It identifies itself using a unique Client ID and specifies exactly what data it needs access to (the Scope).
2. Receives the Authorization Code: After the user approves the request, the Client receives a short-lived Authorization Code from the Authorization Server.
3. Trades for the Access Token: The Client securely exchanges this code for an Access Token. This exchange often involves a secret key (Client Secret) to prove the Client’s authenticity.
4. Makes API Calls: The Access Token is then attached to every subsequent request the Client makes to the Resource Server (the API that holds the actual data, like Google Drive or Facebook photos).

In short: The Client is the application responsible for starting the conversation, proving its identity to the server, and using the resulting token to get the job done.

The Authorization Server: The Trusted Gatekeeper

The Authorization Server (AS) is the heart of the OAuth system. Its entire existence is dedicated to verifying users and issuing secure, temporary credentials. It’s usually part of the identity provider (like Google, Microsoft, or your organization’s internal identity management system).

If the Client is the hotel guest, the Authorization Server is the front desk manager. It holds the master keys, knows the security policy, and decides which temporary keys to issue.

Key Roles of the Authorization Server:

1. Authenticates the User: The AS is responsible for prompting the user to log in (e.g., entering their username and password). Crucially, the Client never sees the user’s credentials.
2. Manages Consent: It asks the user for explicit Consent. This is the screen where you click “Allow” or “Deny” access to specific scopes (e.g., “Allow this app to see your email address”).
3. Issues Tokens: Upon successful authentication and user consent, the AS generates and issues the Access Token. This token is a digitally signed ticket that represents the user’s granted permissions.
4. Token Validation: When the Resource Server receives a request with an Access Token, it often communicates back with the AS to ensure the token is valid, hasn’t expired, and has the correct permissions (scopes).

In short: The Authorization Server is the highly trusted entity that handles all sensitive identity and permission-granting logic, protecting the user’s password from the third-party application.

The Power of Separation

The brilliance of OAuth 2.0 lies in this separation of duties:

• Authentication (Who you are) is handled exclusively by the Authorization Server.
• Authorization (What you can do) is defined by the Authorization Server and consumed by the Client.

This design ensures that your sensitive credentials never leave the hands of the primary identity provider, giving the Client only a limited, revocable key—the Access Token—to perform its specific tasks.

In the digital world, every application we build is a potential target. Yet, far too many development teams still treat security as an afterthought—a quick penetration test tacked onto the end of a project before launch. This reactive approach is inefficient, expensive, and frankly, dangerous.

The solution is the Secure Software Development Lifecycle (SSDLC), and it’s built on one simple, powerful idea: Shift Left.

The Problem with the Waterfall Model

Recall the traditional, sequential Waterfall Model. Security often shows up late, usually in the testing or validation phase.

When a critical design flaw is found late in the cycle, what happens? Development stalls, costs skyrocket, and the pressure to launch often leads to weak patches instead of true fixes. This is the definition of “bolting security on.”

The SSDLC and the “Shift Left” Philosophy

The SSDLC replaces the rigid, sequential approach with an iterative, cyclical one, much like the Agile methodology. In this model, security checks are performed continuously, shifting the responsibility for security from a single QA team member at the end of the project to every team member in every phase.

Security is a Feature, Not a Phase

In the SSDLC, security activities are integrated directly into your existing development sprints:

• Planning: Security requirements are defined alongside functional requirements (e.g., “All user data must be encrypted in transit and at rest”).
• Design: Threat Modeling is conducted to identify and mitigate design flaws before a single line of code is written.
• Implementation: Developers use Secure Coding Practices (Lecture 5!), such as input validation and parameterized queries.
• Testing: Automated tools (SAST, DAST) run continuously in the CI/CD pipeline to flag common vulnerabilities instantly.

Threat Modeling: The SSDLC Superpower

The most critical step in the “Shift Left” approach is Threat Modeling, performed during the Design phase. It forces you to think like an attacker by analyzing how data moves through your system.

How it Works (Using Data Flow Diagrams)

A common technique is the Data Flow Diagram (DFD). By mapping out where sensitive data is stored, processed, and transmitted, you can systematically analyze the risks.

For instance, when designing a simple checkout system, a DFD (like the one we drew) helps identify every point where a threat categorized under STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) could occur.

• Risk Focus: When analyzing the flow of customer PII (personally identifiable information) into the database, you immediately ask: “How could an attacker achieve Information Disclosure here?” This leads you to enforce encryption and strong access controls.

The Business Case for Secure Development

Integrating the SSDLC isn’t just “doing the right thing”; it’s a sound business decision:

1. Reduced Costs: Fixing a bug in the requirements or design phase is up to 100 times cheaper than fixing it in production.
2. Faster Delivery: By finding and fixing vulnerabilities early and automatically, you prevent major security incidents that can halt deployments for weeks.
3. Customer Trust & Compliance: Strong security practices ensure you meet regulatory requirements (like GDPR or HIPAA) and maintain the trust of your users.

The takeaway is clear: Make security an integrated part of your development culture. Stop bolting it on, and start building it in.

Several years ago, I was being appraised for my teaching abilities. The head of the appraisal committee asked me as to which pedagogical framework I employed in my teaching. I was taken aback by the question as I was not prepared to be asked about this. It was not even in my remotest imaginations as to what a pedagogical framework was. Anyhow, I replied that I teach my students by asking a series of questions and getting answers from them, in a way that leads to the final message of the lesson. This is something akin to the Socratic method in teaching. But to be honest, I had never heard about the Socratic method by then. I searched a lot on the web to find out content related to pedagogical frameworks. But I failed to find anything meaningful or useful. A few days back I came across a nice resource on the subject matter. And I am only tagging it here for archival.

Pedagogical approaches to teaching in higher education – Caduceus International Publishing

Pedagogy is the method behind the art of teaching. It considers how students learn and uses that knowledge to develop philosophies, approaches, and techniques for the classroom. Not every teacher has a pedagogy. Especially at the college level, many educators don’t receive formal training in how to teach.

Capsule networks were recently invented by the godfather of deep learning, Professor Geoffrey Hinton. I have always found this new technology both interesting and intriguing. I gathered some valuable videos related to this new technology. These include some lectures as well as some lucid tutorials as well. Notable ideas worth understanding about capsule networks are how capsules work, as well as the dynamic routing using expectation maximization. Newer capsules based on auto-encoders are also nice. You might like these videos. Please leave a comment if you have something to say or if you find a better video.

«

Prev

1

/

1

Next

»

Dynamic Routing Between Capsules

Dynamic Routing Between Capsules

Geoffrey Hinton – Capsule Networks

Capsule networks: overview

Dynamic Routing Between Capsules

Introduction to Capsules by Sara Sabour, Google

Building a neural network FROM SCRATCH (no Tensorflow/Pytorch, just numpy & math)

«

Prev

1

/

1

Next

»

Extension legacy

LAST Tuesday marked an unenviable end to six years of near-absolute power. Gen Qamar Javed Bajwa would not have wanted to go as he did, spurned by friend and foe alike. Even the general public – usually so enamoured of men in uniform – seemed unforgiving as he hung up his boots, with many taking to social media to express their criticism.

Photo by archer10 (Dennis)

The Emotion Machine: Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind by Marvin Minsky
My rating: 5 of 5 stars

I started reading this book in early 2008. Then unprecedented events of life compelled me to pay attention to other things that I was told were more important. Although I believed even then that reading this book was more important. I started reading this book again a few days back and I finished it today. I was curious and wanted to peek into the mind of one of the most prolific thinkers who made it well into the 21st century. My primary stimulus was that I am a student of artificial intelligence (AI). The way we do AI mostly around the world these days is to pick a practical problem and devise a solution for it. Even though the solution is quite smart, looked at from a panoramic point of view, it is only a miniature version of what true AI can be. Mostly we reflect on such AI from the lenses of the AI philosophers. Winning the Turing test can be a goal for a more seasoned professional. However, what should true AI be? How should it behave and grow? and how it should act and react? These are the questions that are defied due to concerns of practicality.

Professor Minsky did a great job in writing this book. It begins with contemplations of how human intelligence evolves from infancy to adulthood. By the way, there are aspects of human intelligence in this book that I am sure that not many people might have thought of before. To this end, it is a great self help book too. I mean you could literally learn loads of ideas as to how to use your own mind more efficiently, intelligently and ethically. If you have children, this book can help your raise them well. This book could literally help you raise a genius.

But even apart from that, this book also has practical ideas as to how to make smart machines. I think this one of those books that will become a standard textbook on any course about engineering true AI.

View all my reviews

Photo by bharatjusta

When it comes to spectral analysis, I would also like to assert that Fourier analysis is going to be enough and sufficient in most of the cases. However, one may subscribe to other methods, such as wavelet analysis, as well. But what do all of these terms mean? Let’s not worry about them right now. We shall talk about simple stuff in the beginning.

In order to make life easier for my audience, I made a screencast of a famous song from Michael Jackson; Billie Jean. It is a well known pop song. And it has all sorts of drum beats, string twists of guitars, and other musical instruments. I am not really well versed with many western musical instruments. But I believe that this pop song is really going to serve my purpose. So, please click on the thumbnail below to open the song in a new tab of your browser window.

First of all I would like to draw your attention to the video. There is a spectral analyzer shown in the video. The analyzer has four boxes with graphs shown in them. As the video plays, you can notice the graphs beating in accordance with the videos. Let me explain these graphs a little bit first.

The graph in the upper left (UL) corner is known as a plot of the Fast Fourier Transform (FFT). Again don’t be confused with the fancy term. In really simple words it plots the different frequencies present in the audio (the song in our case) at any given point in time. It also gives us an idea as what the magnitudes of those frequencies is. What is noticeable about this is that there is white box in the top of the graph that has number in it, and it always keeps on changing its place. Moreover, please notice the way it changes its place. This box has the value of the frequency that has the highest value at any given point in time. As the frequency that has the highest magnitude can change from time to time, depending on what instrument or note is being played at any given point in time, this box keeps on shifting it position along the x-axis.

The way this box changes its position from time to time, remind me of the live dance of late Michael Jackson himself. It appears as if the box is dancing like Michael Jackson. Or at least, it definitely appears as if a dance is going on. Why is that? In my opinion the reason is that Michael wrote the song, composed its music, and choreographed his dance routines by putting all his heart and soul into it. So when he had to perform a live dance, he was moving his body and limbs just in perfect harmony with the changing notes. With every move of his body, he was capturing every change in the notes of the song.

But the white box is no dancer. It is an inanimate object. So why does it move in harmony with the beat of the song. Well, it does not. It is just an exhibition of the most prominent frequency in the song at any given point in time. And as that frequency changes, the box also changes its position. So it appears to be like a shadow of Michael.

What is the point of saying all of this. Let’s review rest of the boxes first. The box in the lower left (LL) corner is a similar plot but on an octave scale. Most music lovers really know what an octave scale is so I am not going to go in the details. To be brief, it is a logarithmic frequency scale. In essence it is also showing what the UL box is showing but on a different scale.

The box in the upper right (UR) corner is the spectrogram. Literally, this is also an exhibition of the spectral (frequcny) contents of the signal; the song in our case.

The last box is the one which is in lower right (LR) corner. This box has a single thread-like delineation in it. It fluctuates along with the music. This is what the music is doing as a function of time. You can think of it as the voltage fluctuation that happens as a function of the beat of the music. What is it anyways? The truth is that this box shows the overall loudness level of the song at any given moment in time. We shall come back to it later as it will help us in understanding various concepts in signal processing.

The last thing is the bar to the left of the analyzer. Now this bar literally shows ups and downs in perfect harmony with the ups and downs of the songs. This is also the loudness level of the song at any given moment in time.

The overall loudness, as the name suggests, is the sum total of the loudness of all the instruments being played in the music at any given point in time. There are different musical instruments involved in the creation of music. There is the sound of the drum. There is the audio of the guitar. And there is the voice of the vocalist. In all, there is a handful of instruments involved. Moreover, each one of them is possibly producing a sound of a different frequency from each other at every point in time. The sum total of the loudness of these sounds of different frequencies at any point in time is what we call as the overall loudness of the audio.Well, it need not be the sum total at all. It can be mean, or an aggregate of any kind. These aggregate loudness levels are shown in LR and the bar to the left of the analyzer.

So the overall loudness has all the information of the audio. We can see that its fluctuation is also in sync with the rhythm of the song. However, a huge problem with the overall loudness level is that it hides a lot of information about the audio. In case of music, we really do not know as to which notes are being played at any point in time. As a result, we remain in complete oblivion about the composition of the music.

Stereo systems actually use the overall loudness in the form of a time-varying voltages to render audible music through their speakers. Voltages are passed to the speakers. And they create audible sounds.

But what if we wanted to know the overall composition of the music? What instruments were played at a particular point in time, what were the notes, and how loud were they? Can we answer these questions? Fortunately the answer to these questions is yes. And we owe it to the genius of an eighteenth century French mathematician who went by the name of Jean-Baptiste Joseph Fourier who invented the famous Fourier transform. Fourier was a major in Napoleon’s army. However, his invention of this transform is bigger than all the military campaigns of the conqueror combined. Actually it would not be an exaggeration to say that Fourier transform has a greater impact than all the wars in history combined. We owe it to Fourier for most of the digital communication we observe around ourselves today.

According to Fourier, all the different frequencies that have been added together are separable. And Fourier transform is the tool to separate them. We see this exactly happening in LL, UL and UR boxes in the analyser. The Fourier transform takes as input what is shown in the LR bow. And creates spectra out of that; what is shown in LL, UL and UR. This is a remarkable contribution of Fourier analysis. As a result of applying it what we get is all the frequencies that make up the music and their respective magnitudes. And we get it for small segments of time. To this end, the Fourier analyzer takes a small segment of music at time (roughly around 25 milliseconds) and reveals the spectral information.

So what is the big deal of performing Fourier analysis. The big deal is that in applying the transform we went from knowing nothing about a seemingly interesting signal, to knowling everything about its spectral makeup. This is a tremendous achievement. Having this information in hand we can understand the mind of the musician as well as train a machine to understand that. Not having this information is tantamount to dealing with random electrical glitches. These glitches are shown in LR.

Photo by frans16611