Design Requirements

I've worked with quite a few clients and customers who've gotten stuck on a single solution. A lot of times this plays out in that some sort of salesperson comes along and sells them on all the products and features maybe a piece of software has that's going to revolutionize the way they do business. Then this customer rolls out this product and it really doesn't meet their needs. I find that largely this happens because they skip a single step, and that step is to really figure out what it is that they need. What are the design requirements?

Why planning first matters

Let's develop a little scenario here. Let's say you want to create a house, and what you do is you skip the steps of designing and architecting and just step into creating the house. Could you create a house that protects you from the elements and meets some of your basic needs? The answer to that is yes. You could build a house that did at least something for you, but it probably is missing a lot of features. It probably wasn't designed correctly, so you're going to have problems down the road. It probably took a lot longer to build than it normally would take because you didn't have this design ahead of time. So now you're going to be stuck with this house that doesn't quite meet your needs, that doesn't quite keep out all of the elements, that doesn't quite do exactly what you want it to do, and it took you a lot longer to build and was a lot more expensive than it would otherwise have been.

In order to guard against this, we start creating an idea and putting it down on paper. We create some sort of blueprint that tells us how we're going to create this house. Then we move walls around and we move features around and we really decide exactly what this house is going to look like and how we want it to function. That way we hand this over to professionals to build and we build it correctly. Or maybe, if we're building it ourselves, we at least have something we can reference, and now we're not ordering extra material that we don't need. Now we know exactly what steps we need to carry out in building this house.

The same thing is true for technology. If we don't have proper planning, then our projects are going to run over budget, it's going to take longer to implement, and it's not going to be exactly what we want. In fact, 70 to 87% of IT projects fail, and largely that's because there's not been enough planning and preparation for those IT projects.

What we really need to do is figure out what our requirements are, what we are trying to accomplish, what our targets are, what our objectives are, what the end result is going to be. From there we can design and architect what this network is going to look like, what the software is going to look like, what it is that we're rolling out, whatever product it is, whatever we're architecting, and we can test it against those objectives. From there we construct it and roll it out, and we know if we're successful or not because we can check it against what our targets and requirements were.

Where design requirements come from

So then the question is, how do we know what our design requirements are? When it comes to security, there are several things that we can pull from to really figure out how to design, to figure out what the design requirements are. One of them is best practices. Others are security models. There are security principles that are out there. There are business needs. There are clients and stakeholders. There are laws and regulations. And there are current security risks that are out there that are known.

Best practices

Let's say we're rolling out a new operating system. That new operating system probably has a set of best practices, things that we should implement on this operating system to make sure we roll it out in a correct way. A specific example of this is, let's say we're rolling out Windows 11. There's a set of best practices, from enabling dynamic lock, to enabling BitLocker, to turning on automatic updates, to enabling the Windows firewall: things that we can implement on this Windows 11 that are best practices to make sure that it's secure.

Models and frameworks

There are also a lot of models and frameworks that are out there that can help us get started. Think of it as if you go out and buy a blueprint of a house that you want to build, but then you take it to an architect to change a few things the way you want them changed. You have a starting point. You have a framework. You have a design that's already a starting point, and then you go from there. Models and frameworks help us do exactly that.

There are a lot of different models that are out there, like the CIA triad, which we'll discuss in a future lesson. You also have things like RBAC, which has to deal with access control and making sure that you implement proper access control. There are also a lot of different frameworks out there. For instance, the NIST Cybersecurity Framework, which helps small and medium-sized businesses. Think of this, once again, as the blueprint of a security program and how they can implement it in small and medium-sized businesses.

Security principles

There are also general security principles. This is kind of more higher level. It's not as specific, but just higher level, what it is that we should follow. You can think of it as kind of a ruler, something to measure up against. Some examples of security principles would be least privilege and separation of duties. We have defense in depth, segmentation, and zero trust, and we'll go more in depth into this in another module.

Business needs

These design requirements are highly affected by the business need. What are the needs of the business and what they're doing? Some examples of business needs are that maybe they need to process credit cards. If it's a business that needs to process credit cards, then they need to follow certain compliances to do that. Or maybe there's a certain level of risk that the business is willing to take on. There's a risk acceptance, and maybe they're risk averse, which means they don't want to take on much risk.

There are also agility needs. Some businesses need to move really fast and they are willing to take on more risk to move fast, while others want to make sure that they're risk averse and so they are going to move a little bit slower because of that. There are also some cost control needs. One of the things of a business is that they need to control costs.

Clients, stakeholders and partners

I've also worked with companies that have had certain business relationships that required them to up their security game. That is, they had certain clients that demanded a certain level of security, and they had to raise up to that level to make sure that they could retain that client. The same thing is true for certain stakeholders of the company, certain vendors and partners that are partnered with that company. So there are certain levels that we may need to attain because of these different business relationships.

As an example, I've had certain clients demand that we carry a certain level of cybersecurity insurance. That is, we had to carry cybersecurity insurance, so if something were to happen, they would know that we would still stay in business. They're relying on our services. They have data. They have different services that they're using. If those were to go away, it would hurt their business. So they want to make sure that we are resilient enough that we can overcome those things, and one of the ways that you do that is with cybersecurity insurance. There's a whole host of other things that they may require in order for us to do business with them.

Laws and regulations

One of the big drivers nowadays is some sort of legal or regulatory compliance. There are a lot of threats that are out there and it's causing a lot of problems, so now laws and regulations are coming in requiring businesses to meet certain levels. This is affecting a lot of small and medium-sized businesses who haven't had to think about security in the past, and now that's what they have to do. They have to roll out certain things, and in order for them to do that they need to understand these legal and regulatory compliance requirements. Here are some examples: some sector-specific regulations. If you're in the healthcare industry, you probably have to follow HIPAA. HIPAA protects the end user by protecting their records and their personal information.

Current security risks

There are also a lot of new security risks that are coming out on a daily basis, so we really do need to understand what the current security risks are and how to guard against them. That is going to affect our design requirements as we implement new technologies. There are a lot of sources that we can go to to find out what these current risks are, things like the OWASP Top 10 or the exploit database. There's a lot of open-source intelligence out there that can help us determine what these design requirements are.

Who to actually go to

I like to think of these as sources, or categories of sources, of where we get our design requirements. But what are the actual sources? Where would we look to actually figure out what the best practices are, what these security models are, what security principles we would implement when we're rolling out our new security architecture?

Here are some of the sources that we would go to. Number one would be ourselves: making sure that we as security professionals have the proper training and experience necessary to implement good security design. There's also a ton of great resources from government agencies to make sure that we're designing and implementing security correctly within our organization and within the networks that we manage. There's also the management team, or the business itself, or the board of directors, or, within the company, just users within the company that are going to have certain demands and certain requirements. So we need to go to them and start that communication to figure out what they want. Vendors also have some great resources on what to implement. Stakeholders and customers may demand a certain level. And there are a lot of online resources that can really help us out in this design requirement.

In the end, creating these design requirements of what we're actually trying to achieve is really going to help us out with the architecting phase, with architecting correct security and making sure we're implementing things correctly.