ISACA CISM – Domain 03 – Information Security Program Development Part 6

44. Enterprise Architecture Part1

Now the term enterprise architecture is something we’ve kind of discussed a little bit earlier where we said there are many architectural approaches that we can use for security. Often we talked about this as being a framework that we can use to help us in designing the overall security. Now, the architectural approach is something that’s kind of a new idea, at least in the last ten years. And because it is kind of a new idea, you might already be working in a large organization where your security program wasn’t really based on an architecture, but kind of evolved as an ongoing process of bits and pieces lacking the actual integration that’s needed. So if you think about it, what we’re getting at here is that we may have even within information technology, a variety of different little silos.

I mean, there’s a lot of organizations and companies where we have a team that just does firewalls, one that just does routing and switching, one that just does the servers and the workstations. And they all have kind of their own things that they do to increase security piece by piece. And it’s kind of fun to actually go into some of these organizations. And here are some typical complaints like if suddenly the communication from one server to the other, from clients to the servers goes down, it’s all it’s a firewall’s fault whether the traffic is even going through the firewall or not. But in that kind of lack of organization or lack of architecture, it could very well be that that’s historically the way it’s always been.

That somebody in that firewall group decided, hey, we are going to bit and piece together some new ideas and rules for increasing security that might not integrate as well as we might have hoped with the other parts of our network. And again, I’m not saying that’s the same of any of the organizations that maybe you’re with, but I’ve certainly run into those types of designs where it doesn’t seem as though they communicate. In fact, another example I remember in working with a bank that they had several data center locations and they had to cross shoot some firewalls to get from the one data center to another data center. And the people in charge of those firewalls said we’re not going to allow you to use OSPF as a routing protocol to be able to exchange routing information about the destinations in each routing center.

And so they had to come up with a very complex solution with a protocol that’s not so easy to implement called BGP. So they had to keep kind of working around because one little piece wasn’t working necessarily with another little piece, but they had a goal to accomplish. Again, you got to think about this as an overall architecture. I’m not saying that was a bad design, but the way in which it was communicated to me lets me kind of see that we had different groups that weren’t really working as an integrated whole. Now, having said that, and especially if you think about that example of the bank situation just in the routing communication, you can see that we can create a very complex situation that we have to work with. And they did have a very complex situation.

And if I keep using them as an example because they had multiple data centers and the way in which BGP works, that if one connection failed, they were supposed to fail over to the other one, and then if the other connection came back up, it didn’t fail over so easily. Unless you really knew the ins and outs of how BGP worked to be able to tweak it, to get it to work the exact way it wants to. Again, a very complex situation on what is a simplistic solution, at least it seemed like it was to me, or should have been. And again, I’m not saying one way or the other if that was good or not for security, but it does create some situations in which as you’re working with security and creating and designing a roadmap to get to a new desired state that really you have a lot of complexity that you have to work with.

And the architectural approach tries to take, as I said, a wider view of the organization as a whole. So again, the goal of architecture is to kind of define the relationships between the various business attributes so that we are trying to work together to not create those silos, as I’ve said, over and over again, to be able to have not people doing the same work, overlapping duties, maybe even an increase in costs, but really trying to get them to work together and hopefully be able to help, even set up the proper roles and responsibilities to get the job of security done and to be efficient.

45. Enterprise Architecture Part2

Now as we talk about the enterprise architecture, there’s several ways we can look at the architecture. If we talk, first of all about the contextual architecture, that’s where we’re kind of defining the relationship between various business attributes. This is where we talk about the who, the what, the when, the where and the how. And again, think about the way in which we phrase it. It is how do these things work in context with each other? Who’s involved? What do they do, when and how does those processes work? The logical architecture would pretty much describe the same elements, but in the term of their relationships. Now, it could be a relationship in which we talk about the way process, by way widgets are made. It could be a relationship about how online ordering is supposed to work. A lot of these things is just understanding the flow of the way in which data might move through the network or the procedures.

You follow for certain, as I said, manufacturing of widgets, et cetera, your physical layer should identify the relationships between the different security mechanisms that execute the logical relationships. So if I’m talking about online ordering, of course I’m going to talk about the actual path that the data is going to travel, that the customer is going to take when it hits that web server, web application, what path it is going to take to get to the SQL Server or whatever database server you’re using. And of course, what is that server again? The physical components, the physical layer, the component architecture should actually list the devices and their interconnections almost, you could say, as have a map of the overall complex organization. Your operational architecture’s job is to describe how your security devices are going to or how your security device deliveries are going to be organized.

46. Enterprise Architecture Part3

Now, as I said, there are a number of different architectural approaches and they’re designed for the Enterprise. Some of them deal partially with security. Some might be exclusively designed around security. Now, the detailed discussion of these specific types of architectures is outside the scope of this course, but they often consist in two basic categories process models or framework models. Now, basic basically, if you think about, again, the idea of architecture, remember it’s tightly aligned with the purpose or linked to the business objectives. And if I want to just throw out another analogy, we could talk about a building architecture actually going to build a building. And one of the things that I hope the architect would ask is what’s the purpose of this building? If it’s going to be a business complex, it’s going to be designed different, differently than if you tell me it’s going to be a theater. And so, really, we look at that architecture as a way of talking about what is the purpose, what are the business objectives? And that’s kind of the goal. Right? Again, is looking at it as a whole rather than as a kind of a piece by piece by piece approach.

47. Controls as Strategy Implementation Resources Part1

Now let’s talk about controls as a strategy implementation resource. Now notice what we’re saying here. Strategy implementation. So controls are considered as a regulatory device, a system, procedure or process that regulates some operational activity. Well, if I just talk about controls as policies and procedures, practices right there we can see the that it does regulate operational activity. Procedures especially tell us step by step how to do things. Our standards tell us the boundaries of which we can operate in the practices tell us the way in which things are done. And this can also include the technologies and even the organizational structures that we use to meet the business objectives such as having the chain of command that you follow for certain types of issues that arise or again just the business objectives, what’s the goal of the company.

These are controls that are designed to help regulate this process and get us to that operational activity. In specific, when we talk about security controls those are often addressing the people, the technology and the processes that are involved that can really institute risk. And of course we know that that risk, if it occurs, if there is a loss of information in any way that it can have a big impact on the corporation, on the organization. So that’s what security controls are doing. They’re addressing people’s input to this. Again, we talked about training and awareness. They’re making mistakes, accidental deletions, being malicious in what they do. And again, with the technology and processes, hopefully I’ve hit those enough times that you’re on target with what we’re looking at as far as the term security controls.

Now remember, the controls do represent often corrective or preventive actions. So as a procedure you could call it a corrective type of an action. I don’t want you to input information in the wrong order in the wrong way. So I’m going to try to correct that particular problem. Preventive controls may very well be controls that we use to verify data. We can see those built into the security of an application. If you’re entering a customer order we don’t want you to put the order number in for their first name, right? So we might have some controls built into that application that prevent that kind of misinformation from being put in. But they can also be used as a deterrent or even as a detective type of control. Obviously we see detective controls in the discussion of intrusion detection where we can hopefully catch the signs of malware being sent to us.

Deterrent controls are used as examples of fences that are eight foot tall with barbed wire. Hopefully deterring you from taking that point of entry into our organization’s facilities but using it. Even small fences and shrubbery is often used as a deterrent control to try to force traffic in a certain direction. Not that people don’t still walk through the shrubs, but not that many do, but all of these are examples of controls. I’m hoping even just by the discussion of the control that I’m putting you outside of just information itself and looking at just data and technology, because as we’ve been talking about, physical security is another issue. And so as I throw out these other ideas, I’m hoping to kind of broaden the scope by which you’re viewing the way in which controls are defined and what they really represent for us.

48. Controls as Strategy Implementation Resources Part2

Now as I mentioned the categories of controls are deterrent, preventive, detective, corrective or compensatory. And I hope that I’ve already hit enough different ideas about examples of deterrent controls. Again, what we’re trying to do is if you’re going to break into our facility we’re hoping to deter you from that with that large fence in the barbed wire and maybe go find some other weaker protected facility. Not that we want you to attack anybody else but if we had a choice again, preventive controls, preventive controls can be simply things like you can’t log on after hours, right? We’re going to prevent you from coming in at certain times of the evening or the late early morning hours as an example again of just a way in which we can look at a preventive control detective.

Controls can be again, from the intrusion detection systems to our having logs and reviewing the logs to see what activities people have been up to to physical security with motion detectors and the rest of those things corrective or compensatory. I kind of mentioned those, some of those as a preventive but also as ways of performing audits, doing vulnerability assessments, looking for problems, trying to correct those issues. And again there’s a lot of different ways in which controls can help us in the mitigation of our risk. Now if we can controls should have automation to them to make it technically infeasible to bypass them. Now what that means is that if there are manual aspects and I use the example of doors with magnetic key locks that’s a manual type of control.

You swipe your magnetic card in front of the lock reader or the card reader the door opens up for you and you can hold it open and allow all sorts of criminals to come walking in. You could bypass those very easily if I made it some sort of automation, like what we call a man trap, where you have to let the first door close completely and then the second door will open or can unlock so you can proceed in. Plus put pressure pads in the floor to detect more the presence of more than one person. Then with that kind of automation unless you can help somebody fly through that setting it makes it very difficult to bypass that type of control.

49. Controls as Strategy Implementation Resources Part3

Let’s take a look at some of the common control practices. And the goal here is, if you think about these common practices, the idea is to make it kind of difficult to bypass the controls, especially if they use some of the following principles like number one, logical Access Control. Now, when we talk about Access Control, we are talking about the authorizations, right? What is a person allowed to do or what is a system, system or process capable of doing that’s? A set of permissions. Now, there are a lot of ideas about Access Control, two very common ones that we would talk about, that we would see in some of our different operating systems. And again, depending on the operating systems, are things like mandatory access control or discretionary access control.

Now, Mandatory Access Control might be considered even more difficult to be able to bypass. The example here might be military records where we have labels of sensitivity or classifications like Top Secret, Secret, Sensitive. And what it does is it says in an operating system running under this kind of guise, it says if a file was created in a top secret type of access, in other words, you logged on, you accessed the top secret realm. If you are viewing documents, if you create new documents, you have no choice as the creator of the document, as to how it’s going to be classified. Because of the way in which you have connected into and where you are, it will be considered top secret. In fact, it will take an independent review to be able to move something or declassify something from Top Secret down below.

Now, that’s called mandatory because there was no choice about it. Discretionary Access Control is how we can view our existing Windows windows as an operating system. It was built around this. And there the permissions. The Access Control is up to the owner of the document or the file. So it doesn’t matter if you wanted to and you’re just a regular user and you create a document if you wanted to, you could say the administrator of this server has no right or no privileges to read this file. And if the administrator tried to open it up, they would find that they don’t have privileges to read it. In fact, the only way they could read it, at least in a Windows solution, is to go into the properties of the file and change the ownership from the person who created it to the administrator. And then, of course, based on the idea of Discretionary Access Control, once you’re the owner, then you can choose who has permissions, but you’d have to go out of your way to do that.

But those are examples, again, of ways in which controls are designed to try to make it very difficult to bypass any aspect of the control. Another thing we look at is a secure failure. And that sounds great, right? Secure failure. All right, well, here’s an example. Microsoft has been known for people to make jokes about the blue screen of death. All right? So why the blue screen of death? Well, here’s the thing. If there’s a failure that causes a system wide failure, such as the blue screen of death, you’ll notice that you can’t do anything. You can’t interact with the operating system. You can’t open files or folders. It may have failed, but it has failed in a secure fashion, as opposed to could have. Just in the old days when I was using Windows three one, if there was a failure of Windows, windows would just slam shut and close, but I would still be in the disk operating system, and I had access to everything I wanted.

So when it failed, it was not secure. It was annoying. Firewalls are the same example. In many cases, when we’re testing firewalls, we put them under what we call stress. We just try to jam that thing full of packets and data and throughput hoping that we can overwhelm the processor. And if we overwhelm the processor and it gets up to that 9900% utilization, would it stop actually looking at packets and making decisions about whether they’re permitted or denied and just kind of fail and say, I can’t keep up, so I’ll let all traffic go through? If it did? By the way, those are one of those firewalls that you want to run away from. We want it in failure. In this case, being overwhelmed with information to fail closed. Right. We want it to be secure. Bye.

• Category: Uncategorized