Security architecture is a combination of two things that, over the last two decades, have been steadily changing. Security architecture, as written in this book, is architecture focused on security. It's not security with an architecture leaning. Many people will talk about security architecture and focus on the security aspect of that term but, by doing that, they ignore the build capability associated with any architecture tower, even in a security architecture tower.
To understand security architecture, you must first understand architecture in general. At first glance, security and architecture are diametrically opposed. Security, by its nature, is meant to slow things down, to break things, and to understand how things can be broken. Architecture, on the other hand, is meant to build things up to make them more useful. It's the process of understanding security and architecture separately that allows you to understand the importance of security architecture.
The following topics will be covered Â in this chapter:
- TheÂ history of architecture and security architecture
- Security in the different architectures, including:
- Security in network architecture
- Security in infrastructure architecture
- Security in application architecture
- Security in virtual architectures
- Security in the cloud
- Architecture layers in an organization
- The different security architecture roles
- The importance of templatization
- Security architecture principles
In order for you to understand what a security architect and security architecture do it's important to understand where security architecture came from. So, let's start with architecture and its history.
Architecture as a practice is young, only starting in the mid-1980s. One of the very first architecture frameworks was the Zachmann Framework, which came out in 1987. John Zachman, created it when he was working with IBM. It was meant to codify how to look for solutions and ensure that no aspect of a solution was missed. People took the Zachman framework and started to adjust it, based on their organization's needs and personality.
That's the thing about frameworks: very few organizations truly follow a set framework, simply because very few organizations are the same as others. Each organization is unique and has its own characteristics. Different-sized organizations have different stakeholders. They have different internal processes. And, as a result, a fixed framework can never truly be ported from one organization to another.
Â But an architecture is not a framework.Â Rather, an architecture, is the end result of a framework.Â Remember, an architecture is about communication of ideas and whatever form that takes has to be usable by the organization. If you create an architecture and that architecture is never used or followed, what is the point of creating it in the first place? The framework is just a structure used to create the architecture and ensure a consistent level of quality for the architecture itself.
Â Because of that, different types of architecture frameworks started to be developed over the years. NIST created their own framework, which was originally very heavily influenced by the Zachman framework. But frameworks have been evolving ever since, each trying to improve how to communicate a solution or an idea. It has gotten to the point where people are more focused on creating frameworks and filling out templates, than they are on communicating.
Today, the ISO has documented over 67 different architecture frameworks (http://www.iso-architecture.org/ieee-1471/afs/frameworks-table.html). The most well-known one is probably The Open Group Architecture ForumÂ (TOGAF). TOGAF, as an architecture framework, is quite useful. It starts from a high-level conceptual state and brings the architecture down to a much more physical interpretation. The problem with TOGAF is that it was created before the concept of security architecture was conceived. As a result, it doesn't take into consideration how to deal with security risk.
The closest that TOGAF ever got to integrating security into their architectural framework was when they created a white paper in 2005 (W055: Guide to Security Architecture in TOGAF), expressing an intent to integrate security and risk management into their architecture framework. But that never occurred and, to this day, TOGAF still considers the only architecture towers to be those that cover networks, infrastructure, applications, and information.
One of the things learned over the years is that security cannot be an add-on. Security must be integrated into all aspects of a solution; otherwise, by nature, vulnerabilities and weaknesses are injected into the solution.
Â That brings us to SABSA. Sherwood Applied Business Security Architecture (SABSA) is a framework that took components of TOGAF and Zachman's to create a uniquely security-based architecture framework. SABSA started in 2007 and has been growing ever since. Like TOGAF, it created several different views, going from a very high-level business view, down to a much more physical/technical view. But, unlike TOGAF, SABSA added a third dimension, which talks about specific security activities.
From a security point of view, SABSA works very well. Unfortunately, it is just about security and it isn't something that is widely adopted among an entire IT organization. As a result, we end up with multiple frameworks in a single organization and that just causes more problems. Which one takes priority? When the different frameworks are in conflict, how do you solve a conflict? Security people tend to have a "my way or the highway" approach to doing business and that doesn't work when the core business of an organization is not security.
There are two other security architecture frameworks that you can think about. The first is the iCode security architecture and the second is the open safety and security architecture framework. We were talking about an architecture framework that is focused on security. Very few architectural frameworks have security built into them and, as a result, you have to tack security onto your architecture approach. And when that happens, like I said earlier, vulnerabilities are bound to occur.
Architecture, when it comes to the field ofÂ information technology space, is all about planning and building. In this day and age, there are typically four separate architecture towers and they are described following the traditional OSI model (from the bottom up). But each architecture tower has led to the continued growth of security architecture.
Network architecture is all about designing network-level structures. Everything from LANs to MANs to WANs, network architecture is all about ensuring that the communication of information from one device to another can occur smoothly and without interruption.
It's important to remember that network architecture is probably the very first place that IT started to plan. Most solutions were originally centered around the mainframe, which meant that any connection was typically in a star topology, where the mainframe was in the center and then connections were serialized outward from the mainframe.
When smaller devices such as servers and workstations came about, architected solutions started to have to focus on client/server topologies. But for those solutions to work, you had to ensure that communication from the client (which was typically a thick application that had one dedicated purpose, which was to interface with the server's application) was able to communicate directly to the server. How could thatÂ be done? Well, that was where networks came about.
Back in the late 1980s and early 1990s, there were several network protocols that were being used. Today, networks at the physical layer are predominantly Ethernet-based but, back then, you had Ethernet (of the 10 M variety only), Token Ring, FDDI, a number of serial protocols including RS-232 (which was used to connect printers and auxiliary devices to computers), and others. Fiber optics cabling was starting to come into vogue so there was great interest in using it, simply because of the speeds that it could provide. But, because of cost, fiber only ended up being put into place for networks covering large areas.
If you go up the OSI stack, you get to the network communication layers, which include the network layer and the transport layer. Today, we make use of TCP/IP. But IP networks didn't become the standard until the early 1990s and, before that, we had things such as AppleTalk (for any of you Apple geeks, the protocol to network Apple computers), IPX, Banyan VINES, DECNet, and many more.
Security? Well, as with all things in IT, security has always come as an add-on. There are these great breakthroughs with regards to networking and the first thing that people do is figure out how to get around the protocols. Remember, protocols and designs have one intended consequence and, typically, two unintended consequences. The same goes for networking. You had this great ability, but it didn't fully meet people's needs. They would have to figure out a hack for how to get around the problem.
When you look at the history of networking, you see many devices that you don't see today, such as bridges and hubs. Bridges were used because they were meant to bridge from one network protocol to another. When we started to standardize on TCP/IP, bridges started to disappear.
You also saw devices that had secondary purposes that aren't used today, such as switches and routers. Switches, like today, were meant to allow for communication between individual computers but in logical groupings. That was the beginning of virtualization. But you didn't have VLANs at the time, so routers were used to control who could access a network or network segment.
At the outer edge of the company, you would have a router, not a switch like today. You could put Access Control Lists (ACLs) on routers and then use those router ACLs to control traffic flow. But soon you started to see people find ways to bypass those ACLs. Routers, by their nature, don't track where traffic originated from and, if you pretended you were responding to traffic originating from inside the company, the router would let you bypass the ACL.
And so the firewall was invented. There needed to be a device that could act like a router, because it needed to control access into the enterprise and direct traffic to the appropriate segments, but it needed to be able to discern where traffic hitting it was originating from. Check point came to prominence because it came up with a technology called Stateful Inspection, whichÂ in simple terms, allowed a router to have a table that was used to track traffic leaving, and traffic returning, and matching the communication.
You could say that the creation of the firewall was the first step down the road of security architecture. When a technology is created, it's announced to great fanfare and is then implemented without thinking fully about the consequences. People like new sparkling toys and like to appear to be doing things, so they act quickly. But quickly isn't necessarily the best way; there will beÂ more on that in later chapters.
Now, firewalls were originally put just at the outer edge of the company. Why would you need firewalls inside when all the problems come from outside, right? Well, network administrators soon came to realize that the view of attacks from outside was wrong. Back around 2000, multiple studies came out showing anywhere from 65% to 90% of all attacks come from inside the organization (which, by the way, hasn't changed). They started to ask, if a firewall worked so well on the outside edge, can it also be used inside the network?
And this led to network zoning or, as it is now called, security zones. The DMZ is the most commonly known security zone and is used to ensure that services are exposed to external customers, but also that those services can't be used as a jumping off point into the internal areas of the network.
And so, security architecture was born. Most security professionals were originally people from the network arena. They understood networking concepts and how to structure them for protection. And, because most security people are frustrated hackers, they understood how to break network protocols for their own benefit.
They started looking at dial-up modems and replacing them with a new technology call VPNs. They started replacing hubs with something called VLANs on switches. Denial-of-Service (DoS)Â attacks started to become less successful because we started to architect multiple ingress/egress points in the network, as well as limiting the amount of bandwidth a specific port or protocol could use. And all these technologies started to be centralized so that they were easier to control and manage.
So, all was good with the world. But an unexpected shift occurred when, because people couldn't bypass simple network barriers, exploitation of the OSI stack at the infrastructure layer began, simply because that was using the network to communicate.
Infrastructure is defined as those things that communicate directly on the network itself. Commonly, they are servers but there are other devices that have very specific functions and that are in the form of appliances. But, at the end of the day, all these devices have a network interface card in them and they where applications will reside.
Back at around the turn of the century, Microsoft was gaining a reputation for having very poor code quality with regards to their operating system. Remember, Microsoft had created an operating system in the midâ1980s called MS-DOS, which allowed for the easy implementation and support of higher-level applications. As applications demanded more and more capabilities and power, operating systems needed to become more and more robust. Plus, because IT was beginning to catch the eye of the more technically inclined, there were more and more people wanting to learn about information technology.
But people, by their very nature, tend to be lazy. That's not necessarily a bad thing but it's something to be kept in mind. If you can find a simple way of doing things, why do something that is harder, even if it is a better way. And that's a lesson to remember when you are doing any security architecture work. The more complex you make something, the higher the likelihood that people won't use it.
People wanted to use all those shiny new tools called computers. But they didn't have the time to learn how to program in BASIC or Fortran. The creation of operating systems made it much easier to use computers. But, as with anything that is programmed, there are going to be issues and errors. Whenever I write a report, I can guarantee that I have made either spelling mistakes or grammatical mistakes. They are unintended but they will exist. The same happened with the creation of operating systems. And it was those issues and errors that were then used to breach company network environments.
Remember, firewalls were being put into place and it became much harder to get into a company's environment. But Microsoft, which was the predominant operating system supplier, and Novell, with its NetWare networking operating system, were more concerned with pumping out solutions to make it easier to use computers and networks than with ensuring the security of their customers. There was money to be made.
So, by the late 1990s, Microsoft was gaining a reputation for having poor coding practices. When you look at the history of Microsoft operating systems, they kept the same core code and then kept adding more and more adaptions to it to make the operating system do what application developers needed or what end customers wanted. And it was this spaghetti code that was causing all these problems.
Patch Tuesday was introduced in 2003 and became a running joke because Microsoft kept having to issue patches to their code. It was getting to the point that they were losing contracts because of the security issues with its operating systems. Microsoft lostÂ a contract in the early 2000s with the US Navy to Red Hat, simply because the Navy didn't trust the Microsoft Operating System. So Microsoft had to do something, otherwise it was going to lose its market dominance.
And so Microsoft established the Trustworthy Computing Initiative in 2002. The Trustworthy Computing Initiative was a major change in the way Microsoft wrote code. It took the traditional waterfall methodology that was used for the delivery of their applications and then integrated a Secure Development Life Cycle (SDLC), to ensure that security was embedded into the process of creating code. Not tacked on at the end, but rather integrated into the day-to-day activities of code writing and creation so that the products output by Microsoft would no longer have so many embarrassing attacks.
There were four areas that were identified as part of the trustworthy computing initiative; security, privacy, reliability, and business integrity. And so application security architecture was born. The concept of hardening operating systems became paramount, as didÂ establishing an understanding of what group policies could do and how a security architect needs to consider these things as well.
Not only that, but interest in the access of the platforms started to take off. At that time, domain controllers were used and were provided with primary or secondary designations. But to access different domains, there needed to be some way of crossing domains. Enter the concept of federation. Single Sign-On (SSO) had existed for a couple of years and Federation was just a logical extension of SSO.
Provisioning, on the other hand, came about because of a consolidation in the identity market. Originally, there were products meant to propagate identities into the various domain controllers to alleviate the lack of a federated solution. Remember, domain controllers were relatively recent inventions and a lot of applications were still using their own identity stores rather than a central repository. So, the infrastructure had to be put into place to drive down the cost of help desk calls and the cost of putting hands on the various platforms.
But there was a second area that was standalone at the time, and that was the workflow products. The concept still stands today, where there are standardized business processes that can be replaced by automation. No need to send documents around for approvals if you already know who needs to approve what. The same goes for hiring â if you know what the role is and what access they need, then you can automate those activities.
The two markets merged and created today's provisioning solutions, which have a combination of pure provisioning as well as a business workflow engine.
Now, as a security architect, you need to be aware of the various infrastructure layer components that you can use in your various security zones. These tools allow the security operations group and their associated security officers to secure the security assets from threats and compromises.
There were other advances in security architecture around this time that should be understood. There were intrusion detection systems, antivirus solutions, and a monster security solution called an SIEM. But they were focused on infrastructure situations. So, like what happened when network controls got too hard, attacks shifted from infrastructure to applications.
All the lessons that were learned when Microsoft created its SDLC through the Trustworthy Computing Initiative were passed along to the creation of applications. But by moving up this one layer, you start to see way too many application developers. Creating applications is much easier than creating a piece of infrastructure with machine language and the associated lower-level languages. The creation of graphical user interfaces, the simplification of code writing, and the variety of languages meant that almost anyone could start to write applications.
And creating an application that doesn't have vulnerabilities? Well, that became a situation where there wasn't a return on investment. So, security people started to take an insurance approach to developing or implementing applications. What would happen if this happened or that happened?
Plus, you had project management offices that were using waterfall methodologies to deliver projects, including projects around application development. So solution architects had to figure out how to deliver their projects quickly in order to meet schedules or improperly determined costs for projects. Using an SDLC? That would take too long and the company was demanding more and more return on investment.
SDLC approaches work for companies that see the ROI associated with it. But, by and large, architects are technical people and not used to talking business. With the push to deliver applications quicker and quicker, a new framework for developing applications came into being â the Agile approach. And IT managers loved it because it was delivering application components faster than ever before. But there was one problem: Agile requires a fair bit of discipline to ensure that what is delivered meets certain quality standards. And that can't happen if Architects don't truly understand how Agile works.
So now you have applications being written quicker than ever but without the discipline to ensure that the code written didn't have any bugs or vulnerabilities in it. Applying SDLC to Agile is difficult because the two approaches are diametrically opposed. Agile is about building small components quickly. SDLC is meant for working with a waterfall methodology and inserting controls. In short, SDLC imposes structure and guidelines that the Agile methodology doesn't.
The security architect had to start taking a bigger picture approach. They had to look at the way applications where being written and provide guidelines around how it should be written and how the code should be checked. In short, they had to start looking at application development more along the lines of quality control rather than insurance or from an ROI perspective.
Now you have various tools that are used for checking code. But the original code scanners could only check maybe 10-20% of the lines of code. The rest had to be reviewed manually. Can you imagine manually reviewing an application with 100,000 lines of code? Not really possible. But reviewing small snippets each time they are written is something that is much more feasible. Security started to become embedded into the application development process.
To this day, I still have an issue with the Agile methodology. I've found far too many projects where Agile is code for develop quickly without any checks and balances and results in having to go back and rewrite the code.
For the security architect, code review is something that is done by those that do a lot of code writing. But most security architects by this time had come up from the networking and infrastructure areas and weren't that aware of how to code. Sure, they could write scripts to automate specific processes, but write in Java or C++? Not going to happen. So what did they do? They reverted to what they were good at, which was network-level and infrastructure-level solutions.
Along comes the application gateway, the XML accelerator, and the web proxy. Security architects decided that, with so many applications being written and being put into place, it wasn't feasible to check all that code. And, besides, many companies were buying applications off the shelf without any guarantees that the applications were written securely. So a âbump in the roadâ approach became standardized.
By putting something like an application gateway between the users and the application itself, you now had a way of protecting the application from itself. You started to look for known good patterns rather than patterns of malicious intent. The vulnerabilities were still there but the ability to exploit them became harder simply because of the bumps in the road that were implemented. Infrastructure was used to protect the applications that were sitting higher up in the OSI stack.
Are you starting to see a pattern? Basically, an architecture is created and then a security architect must come along and figure out how to protect it. Network architectures created? Great, let's look at network level tools. Infrastructure architectures being created? Okay, let's figure out how to protect them now. Applications being developed? Can we use something a little lower to figure out how to protect them?
It's always the lower levels that are used to protect the levels above, simply because of learning curves. But what happens when all those levels are thrown out the window and the company comes up with something called virtual solutions?
Have you ever heard of Moore's Law? It's an observation that one of the co-founders of Fairchild Semiconductor came up with in 1975. Gordon Moore noticed that the power of the semiconductor doubled every 18 months. He changed that to every two years but people never forgot the original 18-month time-frame.
But, over the last decade, the power of processors has been slowing down and you started to have to think about how to decrease costs more and more, rather than think about how to increase productivity more and more. Remember, to get a true return on investment, you have to either decrease costs or increase what you can do with your expenditure.
Well, IT people started to look back at what they had done before. Back when MicrosoftÂ released their first operating system, MS-DOS, a lot of applications were being built to run on DOS. But more and more people wanted simpler computers, so Microsoft came up with a GUI-driven operating systems called Windows. But what do you do with all those applications written to run on DOS? A company isn't just going to throw out perfectly good applications when a new operating system comes out. There needed to be some sort of backward compatibility. So Microsoft came out, in their first set of Windows, with something called a Virtual Machine.
Basically, it was a version of DOS that runs inside Windows. It fakes that it's a DOS machine so that software that runs on DOS can keep on working. But, at the end of the day, this was the birth of the virtual world.
A little earlier, we talked about VLANs and VPNs. Both are logical extensions of virtualization. You use VLANs to fake a logical LAN that is isolated from other network segments. A VPN will fake an extension of a private network. But, in both cases, they're a virtualization of IT concepts.
Around a decade ago, virtual servers started to show up. And these, as you may guess, fake that they are standalone servers. You have the ability to assign CPU, memory, I/O, and other resources to this virtual server, but all these virtual servers could sit on a single machine. There's a bus that runs between each virtual server and the end result is a mini-network all in one contained unit.
Virtualization brought along a number of challenges, though, for the security architect. All security devices are meant for physical networks: real networks, if you will. So how do you, for example, put an IDS in place in a virtualized platform? Well, you virtualize, naturally. The various vendors started producing either virtualized versions of their security devices or they would provide software and you would put the software on a virtual server. This allowed you to have a small, self-contained network complete with security devices.
But what about security concepts? Take, for example, administrators. In a normal, physical network, you would have local administrators for individual servers and platforms. As the concept of security domains expanded, so did the role of the administrator. Then, there was the role of a domain administrator, who had rights over all boxes in their domain.
Virtualization changed that. You then had shrunken networks and security zones, to the point that you could place them on a single platform. There would be multiple servers sitting on that platform. A new role emerged, which can be called a virtual administrator. This is a role that manages the backplane of the virtual network (predominantly called the HyperVisor) as well as all the resources. The god power of a domain administrator, but limited to the virtual network.
Security architects had to start adapting again. When we look at virtual environments, we should take the same view as we would of the controls in an entire domain, but compressed into a virtual environment. The concepts and the principles are the same; it's the technology that has changed. We started to create architecture patterns. What is placed into the ESX? How do you manage the devices on the ESX? Do you have the management traffic out of band or in band? We had to think about how to manage these environments efficiently and still maintain a level of security.
This was extended to Enterprise Service Buses (ESBs). Back when people started expanding application architectures, they started to have to think about how they could do things more efficiently. Many applications were asking for the same pieces of information, just for different purposes. Or, there were common communication patterns that were emerging between applications because of the movement towards XML. So how could you make communication more efficient?
The first thing they did was limit the amount of wiring that was necessary. The ESB just made communication more efficient by applying the same rules to every application's input and output. They all had to make use of the same roles. They had to use encryption. They had to communicate either across HTTPS or SFTP. Standardized architecture patterns started to be put into place and security architecture was no different.
Virtualization has changed a lot of things for IT. For security architects, virtualization has actually allowed us to enforce strict patterns of behavior, simply because the other architecture towers wanted to have consistent patterns of behavior for their applications. The beauty of this is that security architects just had to review one interface and then that pattern could be reused over and over. Much more efficient.
So now we have virtualization, the concept that allows IT to be as efficient as possible with limited resources. But what was the logical extent of this? If virtualization allowed IT to consolidate resources and become more efficient, what would happen if multiple companies started to consolidate? Wouldn't that make the entire IT industry that much more efficient?
And so began the movement to the cloud. Software as a ServiceÂ (SaaS), Platform as a ServiceÂ (PaaS), Infrastructure as a ServiceÂ (IaaS); as a service came into vogue. Everyone was trying to figure out how to leverage products that everyone already had across multiple organizations. Companies such as SalesForce came up with their CRM that was available to everyone. The catch was that there was little in the way of customization. Google and Amazon came out with their IaaS so that you could make use of the massive efficiencies of a large data center but for your small companyâeconomies of scale made available for the little guy.
The same is starting to occur for security products. You can getÂ Identity as a ServiceÂ (IDaaS). There's Federation-as-a-ServiceÂ (FaaS)Â from Ping Identity. Multiple companies provide IDS as a service. And the various SIEM vendors have SIEM as a service.
Here's the catch, though. How do you, as a security person, ensure that you have security in place when you don't have control of the infrastructure, networks, or applications that are being used by your organization? Sure, you have a lot of cost savings associated with putting servers on the Amazon Web Services (AWS) cloud, but at what risk? And are the security capabilities that AWS enough to protect what you are designing?
The cloud has a lot of capabilities but it's still in its nascent stages when it comes to security. Like all that has come before, a wonderful new capability emerges and everyone rushes towards it. And then they realize, "uh oh, maybe it has some gotchas. Better call security and get something designed".
Security architects must always work to catch up to where IT is going in general. The best way to deal with it is to look to old architecture patterns to see if there's a way to protect the new environment. But keep an eye on this space because, unlike yesteryear, the borders of the enterprise are changing. And if they change, how do you deal with a lack of borders?
It means moving away from protecting boxes (such as servers, routers, firewalls, and so on) to protecting information. It's the information that is important after all.
Let's break down security architecture by starting with the architecture component. To create a good architecture, you must have a structure in place that allows you to deal with all the details. Typically, the best way to put together an architecture is from the network layer up. This means understanding networks, infrastructure, applications, information, and business architectures. Each one of these layers has a security component and, as a result, needs to have a security architecture component.
Â But that's only part of what an architecture does. At the end of the day, an architecture is meant to communicate a future state. It's meant to take information from the business and translate that into technical terms for IT people. It is also meant to take information from IT people and communicate it to non-technical individuals.
What we've learned about IT projects is that, if there hasn't been any planning (both short term tactical planning or long-term strategic planning), most projects will either fail to be fully implemented or, when implemented, only a fraction of the capabilities of the solution will be used. Architecture is meant to change that. It's meant to provide the plan to implement a solution specific to a project and it's meant to provide a strategic vision so that the IT project, once implemented, moves the organization down the road to fulfilling. Architecture is probably the most important function that an IT organization can have and, without it, IT becomes nothing but a black hole for expenditures on technology.
Now, let's talk about security. Security is meant to reduce risk. It's meant to consider vulnerabilities and the potential for those vulnerabilities to be exploited. As a result, often, people who work in security are viewed as roadblocks to moving forward. This is an unfair characterization that comes about because people want to move quickly. But by moving quickly, risks and issues can be introduced into a project. A better way of characterizing security people is as individuals who` specialize in a specific type of quality assurance.
The problem security people have is that they typically come from a technology background and are not able to communicate security risks to non-technical individuals. That, combined with a lack of understanding of the business, results in conflicts with other departments. The other issue with security people is that they often come up with problems without a corresponding solution. And this is where the security architect comes in.
The security architect should understand the risks that a security person will find and then be able to come up with solutions that will be acceptable to the business. They should create architectures by looking at each layer and understanding how those individual layers will deal with risk. Dealing with risk needs to be done at different layers within the IT organization as well. The security architect must understand the importance of governance, the creation of strategy and program management, the various security activities, as well as architecture activities, in project delivery, and the roleÂ that operations play in creating architectures.
People tend to misunderstand what security architect is and, as a result, mischaracterize the role they play with the roles of other positions. Often, security organizations will view a security architect as someone who determine risk levels. But that's not what a security architect does. Determining risk levels is only a small component of what a security architect does. Remember, a security architect is an architect that specializes in security, not a security person who can do design. This is a very important distinction.
What's important to understand is that there are different types of security architects just as there are different types of IT architects. Each security architect has an important role to play but they must balance different amounts of business and technical communication.
Now, when you combine both security architecture, you have a function that is meant to provide a strategic vision to reduce the security risk of an organization over a 3-5-year period and a tactical vision to implement IT security projects that will move the organization down the road of reducing the business's security risk.
This book is meant to talk about how to create the various security architecture deliverables in the importance of each. My recommendation to you is to take each of these areas that the book will talk about and create standardized templates. It's with the use of templatization that you can improve the quality of your work, as well as improving the architecture return on investment.
- Governance: When you start talking about security, you must be coming from a place that the entire organization agrees with. That place is governance. This can be things such as policies, organizational oversight, and the principles that are used to ensure an organization is secure. The moment you start talking about security without referencing a governance framework, you are opening the door to disagreements within an organization.
- Strategy and program management: Once you have governance in place, you want to have a vision of what the security of your organization is going to look like. Any architectures that you build must be in alignment with that vision and that's when security architecture strategies come into play. A security architect must be thinking about how to create strategies or how to align their projects with the strategy of the organization. The projects that security architects work on will come from a program driven by the strategy.
- Project delivery: It's in project delivery that most people think security architecture work occurs. It's important to understand that there are two types of projects: security projects and non-security projects. When you're talking about a security project, the security architect is also the solutions architect. When you're talking about non-security projects, the security architect just plays a supporting role to the solutions architect. But, in both cases, the security architect plays an important role.
- Operations: This is security architect typically is involved in higher level one time activities. But operations play an important part in a feedback role. They see how well a project is implemented, since they're the ones that must manage the end result, and they see the risks that an organization has that need to be addressed. Security architecture needs to have operations as an input into everything they do.
Â And that brings us to the different types of security architects.
The type of architectural role depends on a combination of the amount of business interaction and the amount of technical interaction. Remember, security architecture is about communicating with both the business andÂ technical people. But this is a balancing act, and the amount that you deal in one area will dictate what type of security architect you actually are.
The more business focused you are, the higher up the food chain you become. The more focused on technology an architect is, the more closely they are aligned to the actual operations and activities that person deals with. So, for example, if an architect is primarily focused on the business side of things, they are typically up where the CIO or the chief architect is, whereas if they are very technically focused, they're typically going to be a technical architect.
The same goes for the degree of experience. If you've just started, you're going to be a student architect, and maybe even need some sort of certification. But as you gain experience, the need for certification starts to disappear and you start to be referred to as a master architect.
Â The three primary architects that we'll talk about in this book are the enterprise security architect, the project security architect, and the security engineer.
- Enterprise security architects:Â Enterprise security architects tend to deal more with the strategy and program management layer. They have a big picture view on how the enterprise needs to look from a security point of view and will put together a program toward move to that end vision.
- Solution security architects: Solution security architects are the security architects who focus of projects, whether as the solution architect themselves or in a supporting role. Needless to say, such projects are typically security technology focused.
- Security engineers: Also referred to as a technical architect, the security engineer is someone who slowly focuses on the technology for implementing the technology on looking at ways to optimize the technology and to support the technology. They're different from solution security architects simply because they deal with just a technology and not the surrounding business processes.
The one other role you should think about and understand is that of ` the chief security architect. This role is the most senior of all security architects. It is found in much larger organizations, where there are multiple security architects and there needs to be a lead in the security architecture domain. In most organizations, you're talking about a chief architect, and then the Enterprise security architect will report to the chief architect. The chief security architect is a leadership role, deals more with the administration associated with running a group of security architects, and will often be involved at the governance layer.
It will that has been discussed benefits by providing standardized approaches to security architecture, whether that's a standardized template for deliverables or a standardized process for creating those deliverables.
Back in the 1990s, ISO 9000 became something of a fad among organizations. The point was to try and standardize your approach to doing activities so that you could have a continuous, consistent level of quality. This resulted in organizations having standardized processes and using standardized templates for their activities. This is very easily ported to security architecture and allows security architects to dramatically improve the quality that they deliver, as well as provide a return on investment, simply because they're able to do things quicker. The more you do something, the more quickly you get at it.
With each of the layers that we've talked about (governance, strategy and program management, project delivery, and operations), it becomes very important to look for ways to create a standard approach to security architecture activities. One of the biggest issues that organizations have is trying to understand why they should have architecture in the first place. The tendency is to just go out and do something, without thinking first, without planning, and that approach often causes issues and problems delivering projects, but does have the appearance of doing things quickly.
The need to go quickly is the reason why we've seen the rise of the Agile framework. Today, people have come to expect to have things right away. They typically have a lack of patience, and that lack of patience can drive poor decisions. One of the things that I learned a long time ago was that, sometimes, the best decision is no decision. But people tend to want to have the appearance of doing things. Doing is viewed as better than not doing.
Â So, to provide that faster process that organizations are looking for, using a template and using a standardized process helps speed everything up. It allows you to show what the end result will look like and will allow you, as the security architect, to look for ways of speeding things up and improving what you deliver.
In most of this book, we'll talk about standard deliverables and what should be in those standard deliverables, but the best recommendation to you is to create what works best for your organization. This book will give examples, but you know your organization best and, like with any framework, you should adopt and adapt what best suits your organization. Remember, your purpose is to communicate and people will have a level of trust in you if you are consistently doing the same thing.
Security architecture principles are those beliefs that should drive your approach to solutions. They are something that are higher than policies and standards because they drive how to enact and respond toÂ theÂ requirementsÂ of policies and standards. They are, in fact, a characterization of the personality of your role.
When you start working with an organization, it's important to understand that organization's personality. By talking to stakeholders, you can get an understanding of how they view their organization and how they would like to see solutions implemented. Are they open to cutting edge technology or do they want tried and true solutions? What do they value as their organization's crown jewels? Is there an approach that they want to take to developing solutions?
The role of a security architect should have its own principles. Those principles allow you to understand how to interact with any organization and deliver results in your architecture tower. Some of the principles that you should consider when you act as a security architect are the following:
- Understand that security is not the core business: This is the biggest failing of security people and organizations, and is common across all companies. Security people tend to think that their way is the right way. But a security architect must do what is best for the business, not what's best for security. Security will provide a series of risks that the security architect puts a solution together to deal with. And, with that, the security architect starts to add value to the organization and gain the trust of those around them.
- Understand and mitigate risk: The corollary of the previous principle is that the security architect needs to understand the true level of risk and then provide solutions. One of the common issues that comes up is that security people will point out risks but not solutions to mitigate risks. A security architect is a builder, a planner. They must come up with plans and solutions, not just problems. And it's the process of finding solutions that meet all stakeholders' needs that allows trust to be built.
- Communication is key to success: An architect is all about communication. If you can't communicate, you can't understand issues or requirements and you can't get people on board with solutions. An architect must be fluent in communication of all forms. They must be able to communicate verbally when in person, providing presentations, or on phone calls, they must be able to communicate in text form, whether that is in emails or memos, and they must be able to ensure that their communication is available whenever a solution needs to be understood, which means ensuring that designs are documented clearly and concisely. This goes for a security architect as much as for any other architecture tower.
Make sure you communicate continuously through the architecture process, don't wait until the solution is done to do a grand reveal. You want to be floating trial balloons or talking about direction with your stakeholders as you create your architecture artifacts so that, when the work product is completed, no one is surprised and the end result is rubber stamped.
- Don't preach: The implementation of a solution happens best when all stakeholders are on board. To achieve that, the security architect needs to talk to stakeholders at times during the creation of the various architecture artifacts. If you actually listen to your stakeholders, you will know what they are asking for in terms of requirements and will then be able to communicate a design that meets those requirements. Too often, people enter into a situation and have a preconceived view of what the solution should be. They don't listen to what their stakeholders believe and, as a result, the solution implemented doesn't meet the stakeholders' needs. And a solution that doesn't meet stakeholders' needs won't be used.
- All solutions are a combination of technology, people, and processes: Too often, people are sold on new, shiny toy. They want to put in technology for technology's sake and not consider that there are different components to a solution. If you put in technology, who is going to maintain it? What are the business processes that the technology is going to support? Is there integration of other solutions already in place?
If you gathered your requirements properly, a solution will come together naturally. Maybe a lower cost option is to realign business processes. Maybe a better solution would be to offshore to a cheaper country. There are all sorts of solutions that can be found, so make sure you are driven by requirements and be open to solutions that cover technology, people, and processes.
- Governance drives what must be done, not personal opinion: Always be driven by organizational policies and standards, because they are meant to represent what the organization believes and how the organization would like to move forward. If there aren't any policies and standards, make it a point of creating them with the help of stakeholders so that the organization has a common view on how to move forward. If you try to put forward a stance that is not based on organizational policies and standards, then it's your own personal opinion and has the exact same validity as the opinion that is opposite to yours, and no one wins that fight.
There is a view that there is one other area of a solution besides technology, people, and process, and that is governance. It may be that a solution will need a governance component such as a new policy or a review board, or some other governance activity. That means that governance should be thought about when putting together solutions.
- Repeat back to your stakeholders what you are hearing in your own words: Nothing gains trust more than repeating back to your stakeholders what you have been told. It shows to them that you have heard what they are saying and, more importantly, understand them. Most importantly, it ensures that you actually have heard them and understand what needs to be done. Once you've done that, then you can start talking about solutions.
When you work as a security architect, make sure you are completely aware of the principles that you will be following and, if possible, communicate them to your stakeholders. That way, your stakeholders will know what to expect and it will allow you to improve the trust level with your work products.
At the end of the day, it's important to remember that security architecture is an architecture activity that focuses on security and is not a security activity that happens to deal with architecture. There is a big distinction between the two that should be understood simply because of how security architecture came about.Â
Originally, architects would create their IT solutions and then add security on afterward, once they understood what they were doing. But, as technology has evolved, it's come to be understood that architecture has to include a security component in each layer and not just be added on afterwards. It's the add-on effect that will cause vulnerabilities to be included in any solution.Â
Fortunately, this is being understood more and more. As a result, it's getting harder to find old school vulnerabilities, such as those at the network layer, because those issues have been understood and dealt with. That doesn't mean that architects now automatically build security into their solutionsâthat will never happen as long as people take shortcuts to design and implement solutions. But the frequency of incidents and vulnerabilities is decreasing on a per-solution basis. But here's the problem: the more that technology changes and evolves, the more solutions there are and, as a result, the more vulnerabilities there are. The number of vulnerabilities per solution is down, but the number of possible solutions is up, so you see an increase in total vulnerabilities.Â And it depends on the organizational personality that is creating the solutions as well.
So how do you deal with that? The solution has to start at the organizational level. It can't start with a single manager but, rather, from an executive directive. And how do the enterprise executives direct? With the use of governance capabilities. Very few organizations have built security holistically into all aspects of solution creation and implementation by starting from the bottom and moving upward. Top companies have had direction from executives with the use of governance, forcing the organization to meet executive requirements.
The next chapter in this book goes into governance and how security architecture is involved in governance within the organization and within an architecture itself. All architectures have three components, technology, people, and processes, and it's a poor architect that doesn't consider each one of those components. But, I've come to realize that there is actually a fourth component that all solutions have: governance. Remember, an enterprise is typically a business solution for an industry problem. Executives should quite properly be viewed as business architects. The only difference between them and an IT architect or security architect is that the amount of technology in the mix of their solutions is typically minimal.
Question 1: What is the key capability that a security architect possesses?
Question 2: What type of security architect deals with strategy?
Question 3: What was the first architectural framework?
Question 4: What are the three primary components of a solution? Is there a fourth and, if so, what is it?
Question 5: Does a non-security project have a security component?
Question 6: Which layer did security issues start showing up in first?
Question 7: What is the purpose of architecture?