In the previous two videos on Cybersecurity Architecture Fundamentals, we discussed principles that you should follow--essential security principles. The next video, we discussed the CIA Triad, where you could basically use this as a checklist to know that you've done a cybersecurity architecture correctly. In this video, we're going to focus on the cybersecurity architect. In particular, their role, the mindset that they have to adopt in developing a secure solution, the tools that they use-- tools of the trade --and the domains that they have to operate in. All right, we're going to start off with the role and their mindset. Where this all begins is with stakeholders. These are the people that have a vested interest in getting this solution right. So we're going to take a look at two examples here of an architect who is working on a building and an IT architect who's working on building an IT system. In both cases, we're going to start with stakeholders and we're going to take their inputs into the architect. The architect is going to wonder, "Okay, we're building a building, but what kind of building is this going to be? Is it going to be a business? Is it going to be a home?" Well, in this case, we're told it's going to be a home. It's going to be a multi-family dwelling. So it's a townhouse, maybe, for instance. So we have an idea already what it's going to be, what sort of size we want, what kind of price range we want it to be in. Those are the things the stakeholders are giving the architect. The architect is going to take that and develop a blueprint. That blueprint then becomes the plan that the contractors come along and implement. So we've got contractors--who are plumbers and carpenters and things of that sort. They're going to be the ones that do the actual implementation. If the architect shows up on the job site with a hammer in hand, you might be in trouble because that's not their area of expertise. You want these people that are experts in doing and these guys who are experts in planning and coming up with the big ideas. So that's a little bit of analogy. Now, an architect might say this is what I generally want this thing to look like. But we need to take into account some other things after I've kind of come up with the basic sketch of what this is. I need to think about safety and security as well with this building. So, for instance, I want locks on the doors, of course, I don't want just anybody to be able to to walk in. I might put security cameras in each of the units, at least on the outside, maybe on the inside. So that, again, I have an ability to monitor, maybe even alarm systems. I might be concerned about fire in one of the units. So I put a smoke detector on the ceiling in each one of these so that we can detect that. And then, if I actually do have a fire, well, I'd like to have something that we call a firewall that slows the spread of fire from one unit to the next. It doesn't prevent it completely, but at least it keeps it from spreading really, really fast. So these are kind of mitigations things that we add on to the architecture to make it more safe, to make it more secure. And the architect dreams those up and the contractors implement and put those things together. Now let's take a look at an IT example of the same sort of thing. Here once again, we just start with stakeholders. And they're going to work with the architect. The architect, instead of coming up with a blueprint, is going to come up with an analogy to that, which is going to be some type of reference architecture, or some type of architecture overview diagram or diagrams that show the interrelations of the high level components of the system. That then is going to get translated into an actual IT architecture. So here we've got in particular a user who is going to use a workstation, maybe a mobile device, or a desktop device. They're going to come across a network to hit a web server. That's going to hit an app server, which is going to hit a database and we're going to get their data. This is a very simple type of architecture. Now, the architect is then going to ask the engineers--the architect has been doing their work basically from a whiteboard. Think of it this way: architects--whiteboard, engineers--keyboard. This is where they're going to be doing their work as they start implementing this system. This architect now also has to consider what might be some failure cases. This is the difference between a sort of normal IT architect and a cybersecurity architect. The normal architect thinks about how a system will work. The cybersecurity architect thinks about how it will fail. Now, the cybersecurity architect has to first understand how the system is going to work, or they don't know how it might fail. So they have to have that level of understanding. Then they have to add on to it. What are the possible things that could go wrong? So let's ask. What could go wrong with this user? Well, it could be someone stole their password, their credentials, so it's not this user anymore. So what do I need? Well, I'm going to put in multi-factor authentication, a mitigation, a way to check and compensate for that particular risk. What if we've got on this workstation a virus, or if it's a mobile device, maybe it's been jailbroken. Well, if it's a mobile device, I'll add mobile device management software to check for that. If it's another type of device--endpoint detection and response capabilities or antivirus capabilities to check there. And we continue across this. In the case of the network, well, just like over here on this building, we added firewalls in order to keep the spread of a fire from one unit from immediately spreading to another and providing a level of protective isolation. That's what we do with network firewalls. That's where we got that term. So I'm going to add network firewalls here to slow the spread of contagion or attack across this infrastructure. And then ultimately over here, I'm going to encrypt the data that's in the database. And I'm going to ask this IT engineer, whoever it is. And by the way, we'll have different engineers that are specialized in each of these areas. So I might have a database administrator that does the database encryption, a network administrator that implements the firewalls. Someone else who does the desktop, someone else who does the identity and access management capabilities. So all of these engineers are analogous to the different contractors. And the architect in both of these cases is coming up with the big picture, the big plans. So again, if you're thinking of a cybersecurity architect, think whiteboard rather than keyboard. And also think how will the system fail and what do I need to do to prevent that? Okay, now we've covered the role and mindset of the cybersecurity architect. Now let's talk about the tools of the trade. Well, it turns out that in the IT architect world, there are certain common diagrams that architects use. There's a business context diagram, a system context diagram, and an architecture overview diagram. These are just three examples that I think are particularly important. So, for instance, we'll talk with a business context diagram. Here we're trying to show relationships among the different entities in the system. So an example here, we've got a builder, we've got a marketing team, we've got tradesmen who are going to build the building, and then a buyer. And so we're showing the interrelationships amongst those various entities. It's a very high level, line-of-business sort of view. In the next one, the system context diagram, we're going to take that and decompose it further into what it would look like in a system. Now, this is just one aspect, this doesn't show all of them by any means. But here we have a project management system. There's a finance system that's trying to oversee and make sure we can afford to build this thing the way we need to and on budget. Blueprints that we're going to call in and do the building with a permitting system that we need to go off and get those. And then a graphical user interface that interfaces to all of it. That's just a very simple example of how the IT system that supports this business model might look. Then we can move further down into an architecture overview diagram. In this case, now we've got a project database, a scheduler that is getting status and reports that it's generating and then alerts whenever we're overbudget or behind schedule or things like that. So you notice with each one of these, it's a further level of detail, a further decomposition. And as I said, this is sort of the lingua franca, the common language of the architect. Any IT architect should be able to take these kinds of things and understand what they need to do. Now, a cybersecurity architect will look at this and need to understand how the system works. As I said before, they also need to envision how the system might fail. So in doing that, I'm going to take this architecture that my normal IT architect came up with and I'm going to try to put the security into this. Now, that's the typical practice and the way we do it. Remember in the first video, I talked about security principles--five that you should always do and one you should never do. And in the second video, I talked about the CIA Triad: confidentiality, integrity and availability. That's a checklist. So we're going to use those things. And in this video, I'm going to add another tool to your toolbox, and that's frameworks. In particular, a framework like this one that comes from the National Institute of Standards in the US. It's known as the Cybersecurity Framework. And what it does is it spells out--think of that an architect will need to follow certain building codes if they're coming up with a building. If you're an IT architect, we don't exactly have building codes that spell it out to that level of detail, but this is an analogy to that. So we're going to specify in the identify stage, these are the things that you need to do to identify users and data and things of that sort. We're going to spell out how we're going to protect those things once we've identified them. What levels of encryption and access control and things like that that we need. How we're going to detect when we have problems, we will spell that out. This is all listed as a very nice, comprehensive checklist for you to look at and consider if you've covered all the bases in the NIST's cybersecurity framework. How are we going to respond once we've detected a problem? And then how do we recover once we realize that we have now got to get the system all back and going again? So think about this as a cybersecurity architect, I'm going to apply these principles, the CIA Triad and some of these frameworks onto this. Now, that's the typical practice. What often happens is I get called in at this phase-- when the architecture is already done and they say, "Jeff, make it secure." Well, we can do it. That's the typical practice. But it's not the best practice. It's not the best practice because in the same way, you wouldn't like to have the building architect say, "We've got the building built, now come in and make it earthquake-proof." It's a little hard to do now. It would have been a whole lot better if, instead of at the implementation or architecture phase, you had engaged me up here. This is the best practice. This is when we ideally want to be bringing in the security architect and involve them at literally every step along the project lifecycle. So I'm going to do risk analysis and I'm going to see what are the risks in each one of these areas and apply some of these principles and frameworks. I'm going to develop a security policy. I'm going to develop then an architecture that goes along with the overall IT architecture, the normal mode architecture, so that security is not just a bolt on. It's something that was baked in to begin with. And then we add in the implementation. We're looking architecturally at these security principles and these frameworks and applying them throughout the process. This is how the architect applies their mindset, applies their role, and uses the tools of the trade. Okay, now, we've covered the cybersecurity architects role and their mindset. Also the tools of the trade. Now we're going to talk a little bit about the domains that they operate in. These are the cybersecurity domains that are the focus of the cybersecurity architect. So, for instance, they're going to take a look at a user who is coming into a system off of some endpoint device, traversing a network, hitting an application which pulls data from a database. Now, we each one of these are domains in cybersecurity. Identity and access management is where we're looking at the user. We're looking at making sure they're who they claim to be, that they have the right access, rights and things of that sort. That's a whole domain. Endpoint security--making sure their device is secure and can be trusted. The network itself being secure, the applications can't be broken into and the data is protected. We'll talk about each one of those domains and then add two more on top of that, because in fact, what we need to be able to do is take security telemetry and information from all of these parts of the working system, the functional system, and feed those into a monitoring system, a security information and event management capability that monitors all of this and lets us know if there is an intrusion, or if there's some reason that we need to go do an investigation. And then ultimately a response. If I find a problem, I need to be able to orchestrate my response to that problem so that we get it resolved as quickly as possible. These are the seven domains that we're going to be covering in the rest of the series. Thanks for watching. Before you leave, don't forget to hit subscribe. That way you won't miss the next installment of the Cybersecurity Architecture Series.
