Cybersecurity Architecture: Five Principles to Follow (and One to Avoid)

With cyberattacks and data breaches on the rise, it has never been more important to ensure your organization is protected from hackers. This series is about

cybersecurity

architecture

and we will talk about two different areas. Fundamentals, where we will go over and discover what some of the

cybersecurity

principles

are that should be applied to everything you do. And then the second part is about various cybersecurity domains. Here we will explore how to identify vulnerabilities, implement best practices, and defend against a wide range of cyber threats through a comprehensive cybersecurity

architecture

. By the way, I'm an adjunct professor at North Carolina State University.

And there I teach a 400-level course on enterprise security architecture. This video series is based on that course. The bad news is that you won't get college credit for watching these videos. The good news is that there are no homework or exams. So yes. Alright, let's start with the basics of cybersecurity. Alright, we want to start with

five

security

principles

that you absolutely should apply and one that you should never apply. So stay tuned until the end to find out which one it is. The first one we're going to talk about is the notion of "defense in depth." Defense in depth is trying to create an obstacle course, a difficulty for the bad guy.

So if we take a look at an ancient model of security, the castle. Well, the castle was designed with tall, thick walls to keep the good guys in and the bad guys out. And it worked pretty well until you realized that good guys sometimes needed to come out of the closet. And so, we needed to put a door on this thing. Well, the door then became a vulnerability. And then we would try to reinforce it. And then maybe put a moat around the whole thing, because that made it even more difficult. And then the gate with a drawbridge.

Now we have a moat that is more difficult to cross. We have thick and high walls. And maybe we even had an angry dog ​​here on this side. Something to give to a system of security mechanisms, because defense in depth is about not relying on any single security mechanism to keep the system secure. Now, let's go ahead and transition to a modern security example. Here, we have a user who is at a workstation who will traverse a network to reach a web server, which will reach an application server, which will finally reach a database. Now, what would we do for a defense in depth in this example?

Well, one thing you could do here is add multi-factor authentication (MFA). That's a system where I make sure that this user is who he is because I'm asking him for something that he has, something that he is, something that he knows, some combination of those kinds of things. Now, how about here? You could do this if it is a mobile device or an endpoint of some kind: mobile device management (MDM), endpoint management software that ensures that the security policy we have established for the organization is in fact

follow

ed on this device . it has the right patches, it has a long enough password and things like that.

We could also add something like an EDR, which is a kind of next-generation antivirus. An endpoint detection and response capability to ensure this platform is secure. Then from a network standpoint, well, I'll add firewalls to keep the web server secure from the outside and also allow only the traffic I choose to allow back into these more sensitive areas. And then for the application server and the web server, I could do some testing, some vulnerability testing on them, to make sure that those systems are not vulnerable to attacks. And finally, I'm going to bring the data here and encrypt it.

Close it, put access controls around it. As you can see what I've done here, there is no single security mechanism that protects this. If any of these fail, the rest of the system continues to function. And that is the idea we are looking for here. So if we think about it this way: we don't have a single point of failure. We are trying to

avoid

single points of failure. And we want a system that ultimately, if it fails, is safe. That's what we're trying to achieve. And that's what the old model and the new security model were designed for.

The second principle we are going to review is the “principle of least privilege.” The principle of least privilege basically says that I'm only going to grant access rights to people who need them, who are authorized and necessary to do their job and can justify it, and only for as long as they need that access right. For example, in this example, I have three users. This guy doesn't really have a business need, so we don't give it to him. The other guys get the right access. They can demonstrate their need. And the other thing is, even for these guys, the clock is ticking.

I'm not going to give you this right of access in perpetuity, forever. We'll constantly come back and make sure they still need that capability. If they don't, we'll take it away from them too. Now, another notion of the principle of least privilege is tightening a system. Let's say we have a web server like this and the out of the box web server (default configuration) is running HTTP of course because we need it to perform web traffic. But let's say you also activate an FTP service and an SSH service so you can log in remotely. Well, there are some things you could look at and say, "Okay, do I really need this FTP server?" If it turns out I'm not going to use it, I should remove that service entirely.

In SSH, if I don't plan to use it, remove it completely. Because each of these services is potentially expanding our attack surface and making us more vulnerable. Another example of protection is to remove all unnecessary IDs found in the system and change the default names of the IDs we maintain. So, for example, if the administrator ID on this system, as configured, is administrator, let's change that. Let's make it a little more specific. And I will name it my name or I will give it another name. Change all default passwords. We don't want this in a basic setup because the bad guys will know what it is and know how to get in.

Now, another example is this idea of ​​privilege transfer. Let me illustrate that. Let's say there are two people who work for the company and each of them has access rights. So this guy is capable of doing these things. He can do the same things because they play essentially the same role. Now, this guy gets a promotion, a new job, and new responsibilities. Well, you go to the manager and say, "Okay, now I'm doing my new job. I need you to increase my capabilities. And these are the things I need." The manager gives them to you and then also says, "You know what?

Just in case, I think you'll probably need this. Let me give it to you too. That way you won't have to come back and ask." again." Or come back and bother me, is what he really means. The problem with this is that "just in case" is the complete opposite of the principle of least privilege. In fact, what we should do is run an annual campaign recertification. At least annually. Some organizations do it more frequently. And to recertify, I go back and look at all my users and all their access rights and make sure they still have a justified need. doing the same job, you still need all that.

Great, they keep it. This guy, however, no longer needs this ability because his new job doesn't require it. And this thing he got just in case, too. We're going to remove it. So what we're trying to do with the principle of least privilege is grant only the access rights you need for as long as you need them. Hardened systems We're going to eliminate the proliferation of privileges and the principle of " just in case". Our third principle to take into account when it comes to cybersecurity is this notion of separation of duties. That is, we will not have any single point of control.

In fact, what we are trying to do is force the collusion of two bad actors (or more than two bad actors) to compromise the system. But no one person alone can reach an agreement. So an example, in the physical world, would be if you had two people here and you had a door with two locks. And this guy has the key to this lock and this guy has the key to this lock. And what happens is that now, if you use his key to open the door, he still can't open it. He can't open the door alone.

But the two of them together, cooperating, can actually open the door. Therefore, there is no single point of control. Therefore, we have a separation of duties. Now taking a look at another example here, let's say in an IT case, here is an applicant. And this user wants to access this database. So he's going to ask for that. He is going to send the request to him. But then there is an approver who will have to take action on it and say yes or no based on whether we think he should have it or not. Then, if they get approval, they will be given the action they want.

Whatever it is, the transfer of funds, access to the database, the package delivered, whatever. But notice the point here. This person, the requester, is not the same as the approver. They can't be the same person. Because if I were, if I could apply and approve my own application, then there is no separation of duties. Again, what we're trying to do with this is create a necessary case for collusion, which is hard to do because it's hard for a lot of people to work together and keep a good secret. And what we're trying to

avoid

is this single point of control.

The fourth security principle we are going to talk about is secure by design. In other words, we should not consider security as secondary. Think about it this way: if you were designing a building in a seismic zone, you would want this building to be able to withstand the pressure. So you're not going to build the building and then once it's done you come back and say, "Now let's make it earthquake-proof." No, you want to do it from start to finish, from design to completion. So let's look at an example from IT. So when we have a project, we usually start with the requirements stage.

Then we'll move into design, code the object, then install what we've written, then test it, then push it to production. And then, in theory, we should feed back into that loop and continue the continuous development process that way. Well, what we don't want to do is what many people do in these cases: wait until this phase to deal with security, once it is already available. Security cannot simply be an add-on at the end. In fact, it has to be something we are doing at all times and across the board. We look at the security aspects of the requirements.

We incorporate security into the design. We're thinking about secure coding principles along the way. When we install, we do so on a secure system. We are testing and protecting that test data. And then in production, obviously, we continue testing. So security is something we do all the time, but it doesn't start here. Start in these phases. That's what we're really looking for here. Now, if you think of another example, let's say: Whose security is it? Well, we really are all here. We have a designer, an administrator and a user. In reality, all of them are responsible for security in one way or another.

But who does the work begin with? Well, it all starts with this guy here. We need to make sure you are designing in security. In other words, what we are trying to do is make security start all the way. And we want it to be "secure by design," meaning secure from the get-go. That's how we would like it to be. Now, sometimes we will have to make some configuration changes to make it more secure. But this is the goal we are trying to achieve: secure by design, secure from the get-go. Our fifth security principle is the "K.I.S.S." principle.

It means "Keep It Simple, Stupid." In other words, we don't want to make it harder than necessary because that will make it easier for the bad guys and harder for the good guys. To give you an example: we are trying to create a certain level of complexity so that it is not easy for the bad guy to get in. But a lot of times the security department will create this complex labyrinth of things that the good guys essentially have. pass through. And what happens in that case is I start here, okay, I log in. Now I have to go through and finally I think, "Oh, I'm at a dead end." Okay, maybe we'll try this again.

Did you know? It's too much trouble to do what the security department asked me to do. I'm just going to subvert this and end up doing it that way, which of course is not what we're going for. So the lesson here is that if we make it harder to do the right thing than to do the wrong thing, people will do the wrong thing. Therefore, we must be able to make the system secure, but also as simple as possible. So keep it simple, stupid. Below is a real example of howWe do this in security departments. We will create password rules.

So we'll say this is your password and it's equal to this. And it's this because we created a complex set of rules that say you have to start with uppercase, then go with lowercase, then you need a special character, then you have to add some numbers and then you have to have a mix of uppercase and lowercase and special characters and all that kind of stuff. And it has to be very long. And by the way, we need a lot of these. You will have a different one on each system and I will have you change it frequently.

That's it, that's what the user sees, it's a complex maze, and they're going to find a way to do it. And what they're going to do is find a password, type it in, and set up all of their systems with the same thing, which again is not what we were looking for. So what we want to do is understand that complexity is the enemy of security. So we want to make the system complex enough to keep the bad guys out, but not so complex that the good guys have a hard time doing what they need to do.

For example, you may have noticed, well, what about Defense in Depth, which I talked about here? There could be some conflict there because we're trying to set up a system of failsafes to put an obstacle course for the bad guy. We want that obstacle course to be for the bad guy, not the good guy. Okay, now we've gone over

five

safety principles that you should always

follow

. And now the great revelation, the principle of security that you should never observe, and that is security by obscurity. That is, relying on some kind of secret knowledge to make the system secure.

It turns out that secrecy and security are not the same. In fact, what we want is a system that is open and observable. And this guy named Kerckhoff came up with what is now known as the Kerckhoff Principle, which basically describes that. He was specifically talking about a cryptographic system. And he said, basically, that a cryptographic system should be secure if you know everything about it except the key. In other words, the key is the only secret of the entire system. Now, why would this be a problem? Well, it turns out a lot of people and every time you hear this you should run and not walk, but run away when you hear someone say, "I've invented a cryptographic system that is proprietary and will take your plaintext." , you feed it into my algorithm along with a key, and then it will go from cleartext to ciphertext." Okay, great.

The problem is that it's a black box. I can't see how it's working. What if the guy says that It's unbreakable, I've been hacking it for weeks, months, years. The only thing that means is that the inventor couldn't find a way to break it, since everyone, if they had access, in fact. , would break this. And in fact, over time, they will. Even if it is a black box, history has shown that to be the case. So what we want is not black box security, we want box security. crystal. So in this case, what we have is the clear text, it goes into a cryptographic algorithm, which we understand, has been published.

In fact, if you look at the good cryptographic algorithms that we rely on today, they are. things like AES, the Advanced Encryption Standard, and RSA These are algorithms that anyone who wants to know how they work can look them up and see. And the secret, therefore, the security does not come from some secret knowledge of how this works. It is capable of producing ciphertext from cleartext without having to keep this part secret. The only secret is the key. And that's what we want. We do the same kind of things when we talk about secure operating systems or secure applications or things like that.

As long as security is based on secrecy, it's not really something we can trust. Thanks for watching! Before you go, don't forget to hit subscribe. That way you won't miss the next installment of the cybersecurity architecture series.