Hi, Ed Amoroso here and I want to talk to you in this video about something kind of interesting. The idea that sometimes an architecture, or a setup, or the way you snap things together in a network, is not advisable. [LAUGH] It's not always the case that you can just be real creative and connect routers and networks and devices and servers and everything just sort of comes out okay. Now, usually when you do that do that wrong, you get chaos, right? So a network manager will tell you, don't get it wrong, because you won't have the functionality you need. People won't be able to connect to printers or to the Internet or to each other, or get certain basic services like email. Get all that, but people like myself would do cybersecurity also have our set of beefs. The things that we say, wow, don't do that. Like there's some real obvious ones that I'm not even going to bother with like for example, you don't connect to the Internet with no security, no protection, no filtering, no prot. That's a terrible idea. I don't even think I need to explain that one. Sometimes that's called being naked on the Internet. But there's some more subtle cases that I think are worth highlighting, just give you an idea that it's not always super obvious what types of configurations would be inadvisable for connection to units. So one example, pop up a little picture here to show you, would be a case where you have two routers that our local area network is using to connect to the Internet. However, the local area network in some sense is two different segments with our own routers connected to the Internet. And if you do it wrong, then what might happen is that that demilitarized zone, that perimeter network is the shortest path from one client to one server on the network, on the LAN, a terrible idea to be using a perimeter network for normal day to day traffic. It's a kind of thing when you are designing a DMZ just like in the case of for example North and South Korea, the DMZ, that's not a place that you want to be walking to school through, right? It doesn't make a lot of sense. It's not for normal traffic. So you can see on the diagram here PCs, servers, shortest path through the perimeter network, absolutely not advisable. And in general, what tends to happen when you're designing these types of things is something you can take to the bank. Here's a thought that I want to make sure you have in mind. The level of complexity that you introduce into a network is going to be inversely proportional to the protection, which means, you get way complex and you're going to have problems from a security perspective. As you simplify, as you bring the complexity down, you will bring the security up. That is almost the always true. Granted, connecting to the Internet without security all is the simplest case, that's an absurd case, set that side. But complexity tends to be the problem. So we have a little diagram here that short of shows you, the idea that you can have, in a network it's possible to have a very simple perimeter if you had for example, one connection to the Internet. That's a case that makes good sense, you would like to somehow have that. The problem, is that most businesses have these complex requirements for for connecting all over the place. They're connecting to outsourcing providers and third parties and your customers and your employees are all working from home or from the local coffee shop. And you have all these gateways and you end up with not just a complex gateway or a complex perimeter, but you have many of them. Multiple distributed gateways. Good luck keeping track with that, right? So the idea here is that same smaller organizations or smaller work loads tend to be a little bit easier to protect than larger organizations with more complex requirements. What this hints at is a basic design property. Namely, if I have a big complex organization and I don't have an easy way to protect it, is there a way for me to break big into small? Now there's a classic concept that I remember studying when I was in graduate school came from Edsger Dijkstra, probably the greatest computer scientist of all time. And he would allow this architectures for distributing things. It's in a 60, 70s and and 80s computer scientists were realizing that distributed communication amongst cooperating coordinated processes was the most powerful way to design computer systems and networks. And he had this image of elephants and mosquitoes. And I always thought that was a really wonderful way of thinking about things, that an elephant is a big blob of something and from a security perspective, boom, I can take an elephant out with the gun. Sorry for the image. But if you break the elephant up into a bunch of mosquitoes, it's more resilient, it's harder to take out. You have make sure you coordinate the communication, but the protection of each of those mosquitoes is going to turn out to be much easier to do. So keep that in mind as you think about distributed architectures and this concept that with parameters, architectures that are ill advised don't make sense, don't connect the Internet with no security. Don't have these paths that you draw through a DMZ and there may be other ones that you could come up with. And similarly, when you have too many of them, then it becomes extremely difficult to coordinate, to ensure that there's a common uniform policy and really just to manage in general. So I hope these are some useful guidelines that you keep in mind as we go through as you learn more about cybersecurity. So I hope this has been helpful to you.
