Introduction to Cyber Security - Understanding Incident Prevention

All the tutorials in this course:

• Identifying the Modern Threat Environment
• Understanding Incident Prevention
• Preparing for Incident Response and Recovery
• Utilizing Resources and Opportunities

Whenever I hear about a new successful attack involving massive service disruptions or the loss of the private data of millions of people, the first thing I always do is look for reports about what went wrong. It can sometimes take a few weeks before those details become public, but far more often than not, it'll turn out the point of failure was an easily predictable breakdown in simple protocols: someone forgot to apply a software patch; someone chose a weak password for a key account; admin access credentials were never revoked after an employee was fired; root permissions were applied too broadly across the system; sensitive data was transmitted across unencrypted channels...you get the idea.

So here's where we work through all the steps you simply must follow if you want to tighten up your infrastructure. Later in this lesson, we'll talk about the important roles security audits and system monitoring can also play in this process. And then incident response will attract our focus in the next lesson.

Let's get started with an important law of infrastructure design: the principle of least privilege. What that means is that no one user and no one process is ever given more power than they actually need to get their jobs done.

Creating full-privilege root accounts for each member of the team could potential lead to disaster. What could justify allowing marketing types the ability to launch virtual application servers and network routers when all they really need to get their work done is access to the object storage buckets where you keep your sales data? And do you really want the developers - who live by the motto: "move fast and break stuff" - to have the final power over taking your production application off-line - not to mention account spending limits?

Instead, you'll probably be best off creating user groups - one for admins, another for developers, and a third for marketing. You'll then assign just the permissions needed the match the job needs for each group. Marketing could have read-write access to those buckets, developers might have access to test environments that they can cheerfully break as often as they like. And the admins could have more general power over most or even all of your account resources.

All this is just as relevant for traditional, on-premises server operations - or even for control over the routers in your office WiFi networks.

That principle of least privilege focused mostly on authorization - that is, what individuals are allowed to do once they've already successfully logged on to a system. But it assumes that that log on - also known as authentication - was legitimate. As I'm sure you already know, that's something which is far from simple.

Login passwords were introduced, and worked fairly well for some years. But their value is sharply limited. Using easy-to-acquire software, it's fairly straightforward to predict the kinds of simple passwords most people choose and then use them to gain full access to restricted systems. Many systems therefore require minimum complexity standards for all passwords. Those might include both upper and lower case letters, numbers, and non-alphanumeric characters. Simple dictionary-based words can also be forbidden. But most users aren't particularly creative when it comes to dreaming up passwords. And even if they were, human memory generally isn't good enough to memorize all but the simplest and most predictable username-password combinations.

Worse yet, folks will often reuse even good passwords for multiple accounts. So once any one of those accounts is breached, an attacker will have access to every other account that was protected by the same combination. When you consider how many dozens and dozens of restricted access services most of us use, it's unreasonable to expect people to manage so many authentication pairs in their minds. And writing them down on post-its that are stuck to the side of monitors is definitely not helpful.

For all of those reasons, security experts have been predicting the end of password-use for decades already. I personally haven't seen strong evidence that it's actually happening though. But the industry is actively searching for useful alternatives.

MFA doesn't necessarily replace the need for a password, but it does add some strength to it, by forcing users to present proof of who they are beyond the "something-you-know" password. Single sign-on requires you to create and memorize fewer passwords, which would hopefully make it easier for you to make the few you do use stronger. And password vaults allow you to use as many extremely strong password strings as you like without having to remember any of them.