Chapter 11: Security – Protecting Systems from Threats

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

If you reveal your secrets to the wind, you should not blame the wind for revealing them to the trees.

That quote from Khaled Gibran, it kind of hits hard when you're thinking about software architecture, right?

Because a huge part of the architect's job is making sure those secrets, your data well, they don't get revealed to the wrong people.

Welcome to the deep dive.

Today, we're really digging into software security architecture.

We're pulling everything strictly from Chapter 11 of software architecture in practice.

Our goal here isn't just high level talk.

We want to give you the tactical blueprint, you know, the actual patterns and design thinking architects use to build systems that can actually defend themselves.

And that defense really starts with defining what you're aiming for.

For architects, system security boils down to what we call the CIA triad, confidentiality, integrity and availability.

The CIA triad.

These are basically the three pillars we're constantly trying to uphold against attacks.

Okay, so let's break those down.

Confidentiality, what are we really protecting there?

Confidentiality is all about protecting data or services from anyone who isn't authorized to see or use them.

Think about, say, your private tax returns online.

Preventing a hacker from viewing those, that's maintaining confidentiality.

It's fundamentally about controlling who sees what.

Okay.

And integrity.

Integrity is making sure that the data or the services haven't been messed with, that they haven't been manipulated by someone without authorization.

Like changing a grade on a transcript.

Perfect example.

If someone hacks in and changes your grade, the system's integrity has been compromised.

It's about the trustworthiness, the correctness of the information.

And the third one, availability.

This just means making sure the system is actually up and running for the people who are supposed to be using it.

So even under attack.

Yeah, exactly.

Like if a huge distributed denial of service, a DDoS attack, hits an online store, but you can still place your order, that system has successfully maintained availability for its legitimate users.

Got it.

So when engineers try to figure out all the ways those three pillars CIA could potentially be knocked down, they use something called threat modeling.

They do.

And a common technique within that is building an attack tree.

You might know about fault trees, which map out how systems fail naturally.

Right.

Like hardware failure or a software bug.

Well, an attack tree is similar, but it maps out malicious intent.

The root of this tree isn't a system failure.

It's a successful attack.

A compromise of confidentiality, integrity, or availability.

And the branches.

The branches and leaves represent all the specific steps the stimuli an attacker might use to achieve that success.

It's a way to systematically think through potential vulnerabilities.

Okay, that makes sense.

It's like mapping the enemy's possible moves.

Precisely.

Now you really can't, and that usually means PII, right?

Personally Identifiable Information.

Yes, PII.

The NIST definition is pretty good here.

It's basically any information that can be used to distinguish or trace who you are.

Think social security numbers, maybe biometric data, birth dates.

Plus other linked data.

Plus things linked to you like your medical history or financial records.

That combination is PII.

So for an architect, this isn't just about keeping hackers out, is it?

It's also about controls inside the organization.

That's a critical point.

You absolutely need policies defining who, even within your own company, gets to see PII.

And the architecture has to support that.

How so?

Well, think about developers or testers.

They often need data that looks real to do their jobs.

But should they see actual customer PII?

Almost never.

Right.

Too risky.

Exactly.

So the architect needs to design in ways to obscure that data using techniques like tokenization or anonymization so that even internal teams work with safe, non -sensitive information.

Okay.

So we know what we're protecting.

The CIA triad, PII, and we thought about attack trees.

How do we structure the actual security requirements?

That's where the security general scenario comes in.

It's basically a template, a structured way for the book to define a specific security concern.

It has six parts.

Six parts.

Okay, let's unpack this.

Yeah.

We can group them, maybe.

First, you need to identify the attacker and the attack itself.

That's the source.

Is it human?

Another system?

Internal?

External?

And the stimulus, what are they trying to do?

View data.

Change data.

Crash the system.

Okay.

Source and stimulus.

Got it.

What's next?

Then you define what's being targeted and under what conditions.

So the artifact is the specific thing under attack.

Maybe a particular database, a user service, a specific component.

And the context.

That's the environment.

What state is the system in when the attack happens?

Is it online, offline, behind a firewall, or exposed,

fully working, or maybe already partially degraded?

Right.

The situation on the ground.

Exactly.

And then, arguably the most important parts for the architect.

Yeah.

Defining the desired outcome.

This involves the response and the response measure.

Okay.

The response is what we want the system to do.

Yes.

The goal, usually it's maintain CIA.

But it could also be things like identifying who did what, which involves non -repudiation, or recording actions for auditing, or notifying the right people.

You mentioned non -repudiation there.

Can you clarify that one a bit?

It sounds legalistic.

Ah, yeah.

It kind of does.

Think of it like getting a certified mail receipt, but digitally.

It guarantees that neither the sender nor the receiver of some message or transaction can later deny that it happened.

So you can't say, I never sent that command.

Or the system can't claim I never received it.

Yeah.

It uses things like digital signatures to provide that provable link.

It's really important for accountability.

Okay.

And the response measure.

That sounds like where the rubber meets the road.

Totally.

This is about metrics.

How do you know if your security design actually works?

You need to measure things.

Like, how often do attacks succeed?

What's the financial damage?

How quickly can we detect an attack?

And crucially, how long does it take and how much does it cost to recover?

So it forces you to think in concrete terms about risk and success.

Precisely.

It moves security from just a vague wish into something specific and measurable.

Like the example scenario they give.

A disgruntled employee tries to modify the pay rate table during normal operations.

It specifies the source, stimulus, artifact, environment.

The unauthorized access is detected.

The system maintains an audit trail and the correct data is restored within one day.

See?

The response and response measure are very concrete.

You know exactly what success looks like and how to test for it.

That makes a lot of sense.

It turns the abstract into something actionable.

Okay.

So that general scenario defines the problem.

Now for the really interesting part, I think.

The solutions.

The architectural tactics.

Right.

And the book organizes these into four useful categories, kind of mirroring how physical security works.

Detect, resist, react, and recover.

Detect, resist, react, recover.

Got it.

Let's start with detect.

Okay.

Detect attacks, tactics are all about spotting malicious activity as it's happening or just after.

A big one is detect intrusion.

How does that work?

It usually involves comparing network traffic against a database of known bod patterns, like specific attack signatures, SysBunis IP addresses, weird protocol usage, things like that.

You also need ways to detect service denial, often by comparing current traffic levels and types against historical norms to spot anomalies indicative of a DOS attack.

And verifying messages.

Yes.

Verify message integrity.

This is often done using checksums or more commonly hash values.

The cool thing about cryptographic hashes is that even changing a single bit in a huge file will result in a completely different hash value.

So it's instant proof of tampering.

Instant poof.

If the hash calculator doesn't match the expected hash, you know the message or file has been altered.

Okay.

Detection is key.

But ideally, we want to stop attacks before they succeed.

That brings us to resist.

Exactly.

Resist attacks is the largest category.

These are your main defensive walls.

And probably the most fundamental is the sequence of identification, authentication, and authorization, often called AAA.

Right.

Identify, authenticate, authorize.

First, identification.

The user claims who they are, usually with a username or maybe an IP address.

Then?

Authentication.

The system verifies that claim.

This is where passwords come in or maybe two -factor authentication, biometrics like fingerprints, or even those squiggly udder CPTCHAs.

Ah, the CCAPPTCHAs.

We all love those.

Yeah.

Well, that moment of friction, that annoyance you feel, that's actually the authenticate actor's tactic working.

The system is making sure you're likely human and not a bot trying to log in.

Fair enough.

So once you're authenticated.

Then comes authorization.

This is about granting the right level of access.

Just because you're authenticated doesn't mean you can do everything.

Authorization checks your role or permissions and limits what specific actions or data you can access.

Resistance also seems to involve sort of building walls within the system itself, limiting access points.

Definitely.

Tactics like limit access and limit exposure are crucial.

A classic example architects use is the Demilitarized Zone, or DMZ.

Can you describe that?

Sure.

Imagine your internal trusted network where your core servers live.

Now imagine the Wild West of the public internet.

A DMZ is like a small, heavily guarded buffer zone, a separate network segment that sits between the two.

Guarded how?

Typically by two firewalls.

One firewall filters traffic from the internet into the DMZ, and another filters traffic from the DMZ into your trusted internal network.

Usually plays public facing services, like web servers, in the DMZ.

It severely restricts the types of traffic and the number of direct access points to your critical internal systems.

So it contains the potential damage?

It limits the exposure, yes.

It's a form of architectural segmentation.

And for protecting data itself, especially when it's moving around.

That's where encrypt data comes in.

Using encryption, either symmetric or both sides share a secret key, or asymmetric with public and private keys, is essential for keeping data confidential.

Especially when it's traveling over untrusted networks like the internet.

Okay, one more resistance tactic that sounds really important is validating input.

Oh, absolutely critical.

Validate input might be one of the most effective early lines of defense.

You have to rigorously check, clean, and sanitize everything that comes into your system from an external source.

Why is that so vital?

Because so many common attacks, like SQL injection or cross -site scripting, XSS, fundamentally work by tricking the system into executing malicious commands that were hidden inside what looked like normal user input.

If you validate properly, you stop those attacks right at the door.

Okay, so we try to detect, we try to resist, but sometimes attacks get through.

What then?

We need to react.

Right.

React to attacks.

Tactics are about damage control, once an intrusion is suspected or confirmed.

Things happen fast here.

The system might need to automatically revoke access.

Even for legitimate users?

Yes.

Even for potentially legitimate users, perhaps even administrators, if their accounts are suspected of being compromised or if a broader attack is underway.

You limit access to sensitive resources immediately to contain the breach.

Makes sense.

What else?

You also need mechanisms to restrict login.

For instance, after maybe three failed login attempts from the same IP address, the system might lock out that address for a period.

Maybe doubling the lockout time with each subsequent failure.

Discouraging brute force attempts.

Exactly.

And finally, you need to inform actors.

This means automatically notifying system administrators,

security teams, or maybe even other connected systems that an attack seems to be happening.

Okay, detect, resist, react.

And the final R is recover.

Recover from attacks.

Now, some of this overlaps with availability tactics we discussed elsewhere.

Restoring service, feeling over to redundant systems.

But security has a couple of unique recovery focuses.

Like auditing.

Yes.

Audit is huge for recovery and future prevention.

Maintaining detailed, secure audit trails logs of who did what, when, from where is essential.

Why secure audit trails?

Because attackers will try to erase their tracks.

The logs themselves need to be tamper -proof.

These trails are how you investigate after an incident, figure out how the attackers got in, what they did, and how to fix the vulnerability.

And we mentioned non -repudiation earlier under response, but it feels like a recovery aspect, too.

It serves both.

In recovery, non -repudiation mechanisms, like those digital signatures, provide legally admissible proof of transactions, which can be vital for resolving disputes or pursuing action against attackers after the fact.

Wow, that's a lot of tactics.

It seems overwhelming to make sure you've covered all the bases.

It can be.

That's why the book suggests using a tactics -based questionnaire.

How does that help?

It basically turns all these tactics we just discussed into a checklist.

For each tactic, you ask, does our architecture support this?

Yes, no.

If yes, how?

What are the design decisions?

If no, why not?

What's the risk we're accepting?

So it forces a systematic review and documentation.

Precisely.

It ensures you've consciously considered each aspect of security, identified tradeoffs – maybe you sacrificed some security for performance – and documented the rationale.

It brings structure to the design process.

Okay, that's a powerful tool.

Now, how do these tactics often get bundled together in real -world architectures?

Are there common patterns?

Yes, definitely.

The book highlights a couple of well -known security patterns that implement many of these tactics.

A common one is the intercepting validator.

Intercepting validator.

What does that do?

Imagine putting a dedicated security checkpoint – a piece of software – right in the path of messages flowing between a source and a destination.

That's the validator.

And its main job.

Its primary job is usually to implement the verify message integrity tactic, using those hashes we talked about.

But because it sees all the traffic passing through, it's a natural place to also add logic for detect intrusion and detect service denial.

So it packages up several detect tactics.

Exactly.

It centralizes a lot of that detection logic.

Sounds useful.

What's the catch?

Performance is the big one.

Every single message has to go through this extra hop and be inspected, which has latency.

And the intrusion detection part needs constant updates because attackers are always creating new signatures.

So maintenance is ongoing.

Okay.

What's the other major pattern mentioned?

The intrusion prevention system, or IPS.

This is often a more heavyweight solution.

Frequently a dedicated hardware appliance or a sophisticated software component.

How does it differ from the validator?

While a validator might look at individual messages, an IPS typically analyzes overall patterns of usage across the network or system.

It's looking for broader, more complex, suspicious activities, not just single bad messages.

So it's more sophisticated.

Generally, yes.

Yeah.

And crucially, it's not just detecting, it's preventing.

It can actively block malicious traffic or connections based on the patterns it identifies.

It covers most of the detect attacks tactics and many of the react to attacks tactics, like revoking access implicitly by blocking traffic.

And the trade -offs for an IPS.

Similar to the validator really, performance cost, because it's doing deep analysis.

And it absolutely requires constant updates to its database of attack patterns to remain effective against new threats.

These are often commercial products, precisely because maintaining that database is a huge effort.

The book also briefly mentions patterns like compartmentalization and distributed responsibility.

Right.

Those directly mapped to the limit access and limit exposure resistance tactics we discussed.

Compartmentalization is about dividing the system so that a breach in one part doesn't automatically compromise others, limiting information exposure.

And distributed responsibility.

That's about limiting the scope of actions, making sure no single person or component has excessive power.

For example, requiring approvals from multiple parties for critical operations.

It spreads out the control to reduce the risk of misuse or compromise.

Okay.

So wrapping this all up, if you had to distill the key message for someone designing a secure system, what would it be?

Well, I think there are three main takeaways from this chapter.

First, your ultimate goal is defined by the CIA triad confidentiality integrity availability.

That's what you're defending.

Second, you need a structured way to define the specific threats you face.

And that's what the general scenario gives you source, stimulus, artifact, environment, response and measure.

And third.

Third,

your architectural toolkit for building that defense comes from those four categories of tactics.

Detect, resist, react and recover.

Security isn't some magic feature you add later.

It has to be designed and using these kinds of tactical building blocks.

It really drives home that security is an integral part of the architecture itself, not just, you know, something bolted on at the end.

Absolutely.

It has to be woven into the fabric of the design from the start.

You know, thinking about those tactics, especially authentication and maybe some of the reaction steps really brings up that tension we sometimes feel as users.

The friction.

Security often makes things harder to use.

Exactly.

Which leads to a final thought for you, our listener, can maybe chew on.

We often see security and usability as being in conflict.

Is that burden, the complex passwords, the frequent re -logins, the TPAP ECHAs is just a necessary evil we have to accept for good defense?

Or could it be that making a system securely easy to use is actually the better long term Because it encourages people to actually use the security features properly.

Where does that balance lie?

Something to think about.

We really hope this deep dive gave you a much clearer picture of the tools and thinking that go into software security architecture.

Thanks for joining us.