37,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Gain practical experience of creating security solutions and designing secure, highly available, and dynamic infrastructure for your organization
Key Features
- Architect complex security structures using standard practices and use cases
- Integrate security with any architecture solution
- Implement cybersecurity architecture in various enterprises
Book Description
Solutions in the IT domain have been undergoing massive changes. There was a time when bringing your own devices to work was like committing a crime. However, with an evolving IT industry comes emerging security approaches.
Hands-On Cybersecurity for Architects will help you to successfully design, integrate, and implement complex security structures in any solution whilst ensuring that the solution functions as expected. To start with, you will get to grips with the fundamentals of recent cybersecurity practices, followed by acquiring and understanding your organization's requirements. You will then move on to learning how to plan and design robust security architectures, along with practical approaches to performing various security assessments. Once you have grasped all this, you will learn to design and develop key requirements, such as firewalls, virtual private networks (VPNs), wide area networks (WANs), and digital certifications. In addition to this, you will discover how to integrate upcoming security changes on Bring your own device (BYOD), cloud platforms, and the Internet of Things (IoT), among others. Finally, you will explore how to design frequent updates and upgrades for your systems as per your enterprise's needs.
By the end of this book, you will be able to architect solutions with robust security components for your infrastructure.
What you will learn
- Understand different security architecture layers and their integration with all solutions
- Study SWOT analysis and dig into your organization’s requirements to drive the strategy
- Design and implement a secure email service approach
- Monitor the age and capacity of security tools and architecture
- Explore growth projections and architecture strategy
- Identify trends, as well as what a security architect should take into consideration
Who this book is for
Hands-On Cybersecurity for Architects is for you if you are a security, network, or system administrator interested in taking on more complex responsibilities such as designing and implementing complex security structures. Basic understanding of network and computer security implementation will be helpful. This book is also ideal for non-security architects who want to understand how to integrate security into their solutions.
Neil Rerup is the President and Chief Security Architect of an architecture firm that provides architectural services (enterprise and solution) to enterprises across North America. He is an enterprise architect who came out of the world of cybersecurity. He has worked on a number of projects for enterprises around the world and has worked in various architecture domains, including security, networking, and applications. He was responsible for the security architecture for the Vancouver 2010 Winter Olympics, securing the critical infrastructure of numerous utilities, and is also responsible for large enterprise solutions for companies around the world. Milad Aslaner is a mission-focused security professional with more than 11 years of international experience in product engineering; product management; and business evangelism for cybersecurity, data privacy, and enterprise mobility. He has been an award-winning speaker and technical expert at global conferences, such as Microsoft Ignite, Microsoft Tech Summit, and Microsoft Build.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 555
Veröffentlichungsjahr: 2018
Ähnliche
Hands-On Cybersecurity for Architects
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Vijin BorichaReviewers: Diya Qudaih, Gregory Saxton, and Abhijit MohantaAcquisition Editor: Prateek BharadwajContent Development Editor: Nithin George VargheseTechnical Editor:Prashant ChaudhariCopy Editor:Safis EditingProject Coordinator: Virginia DiasProofreader: Safis EditingIndexer: Aishwarya GangawaneGraphics: Tom ScariaProduction Coordinator: Shantanu Zagade
First published: July 2018
Production reference: 1280718
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78883-026-3
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the authors
Neil Rerup is the President and Chief Security Architect of an architecture firm that provides architectural services (enterprise and solution) to enterprises across North America. He is an enterprise architect who came out of the world of cybersecurity. He has worked on a number of projects for enterprises around the world and has worked in various architecture domains, including security, networking, and applications. He was responsible for the security architecture for the Vancouver 2010 Winter Olympics, securing the critical infrastructure of numerous utilities, and is also responsible for large enterprise solutions for companies around the world.
Milad Aslaner is a mission-focused security professional with more than 11 years of international experience in product engineering; product management; and business evangelism for cybersecurity, data privacy, and enterprise mobility. He has been an award-winning speaker and technical expert at global conferences, such as Microsoft Ignite, Microsoft Tech Summit, and Microsoft Build.
About the reviewer
Abhijit Mohanta works as a malware researcher for Juniper Threat Labs. He worked as malware researcher for Cyphort, MacAfee, and Symantec. He has expertise in reverse engineering and experience working with antivirus and sandbox technologies. He is the author of the book Preventing Ransomware: Understand, Prevent, andRemediate Ransomware Attacks, published by Packt Publishing. He has a number of blogs on malware research, and also has a couple of patents related to malware detection.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Hands-On Cybersecurity for Architects
Dedication
Packt Upsell
Why subscribe?
PacktPub.com
Contributors
About the authors
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Conventions used
Get in touch
Reviews
Security Architecture History and Overview
The history of architecture
The history of security architecture
Security in network architecture
Security in infrastructure architecture
Security in application architecture
Security in virtual architectures
Security in the cloud
Security architecture
Architecture layers in an organization
The different security architecture roles
The importance of templatization
Security architecture principles
Summary
Questions
Further Reading
Security Governance
Security principles
Developing principles
Sample security architecture principles
Security architecture policies and standards
Policy development process
Interview individual stakeholders
Agree upon areas for policy development
Discuss policy options
Review draft policy documents
Final sign-off of policy document
The policy document
Language of policies
Security policy and standard areas
Security Architecture Guidance (SAG) document
Security architecture guidance for projects
Information-based security
Authentication/authorization controls
Access controls
Data in flight security
Data at rest security
Audit logging
Summary of requirements in an SAG
Summary
Questions
Reference Security Architecture
Reference security technology architecture
Border protection
Detection services
Content control services
Configuration management
Auditing services
Physical security technologies
Identity and Access Management
Cryptographic services
Application security
Reference security process architecture
Personnel processes
Data control management
Architecture
Infrastructure processes
Core SOC processes
Intelligence
Access management
Business continuity/disaster recovery
 Security toolset
Compliance
Business engagement
Process improvement
Reference Security People Architecture
Security oversight
IT risk
Security engineering
Security operations
Identity and Access Management
Summary
Questions
Cybersecurity Architecture Strategy
Cybersecurity architecture strategy
 Leveraging the Reference Security Architecture
 Requirement gathering for strategies
Current state assessment
Environmental variables
Future wants and needs
Strengths, Weaknesses, Opportunities, and Threats (SWOT)
Initiatives (both direct and indirect)
Roadmaps
Annual review
Metrics
Summary
Questions
Program and Strategy Level Work Artifacts
Reference security architecture
Key decision documents
Risk register
Understanding risk
Monitoring risk
The risk impact assessment and the risk register
Final measurement of risk
Whitepapers
Evaluation of the current state
Summary
Questions
Security Architecture in Waterfall Projects
Overview of waterfall project delivery
The difference between the Solution Architect and Supporting Architect
Initiation phase
Requirement gathering phase
Design phase
Build phase
Testing phase
Production Turnover phase
Comments on the Agile methodology
Summary
Questions
Security Architecture Project Delivery Artifacts
Requirements Gathering Documentation
Requirement-gathering process
Requirements-gathering spreadsheet
Requirements document
Requirements Traceability Matrix (RTM)
Vendor selection
Security-design assessments
SDA project plan
SDA checklist
SDA workbook
SDA executive summary
Test plans
Types of testing
Build documentation
Installation table
Database table
Administrator table
Username tables
URL tables
Additional information
Summary
Questions
Architecture Design Document
Approaches to the ADD
Header sections
Purpose, summary, and usage
Executive summary
Scope
Compliance
References to requirements
Target architecture
Business architecture
Data and information architecture
A special note on tokenization
Application architecture
Infrastructure architecture
Concluding sections
Gap analysis
Recommendations
Summary
Questions
Security Architecture and Operations
Strategy feedback loop
Security operations strategies
Improvement in capabilities
Inputs into security architecture strategy
Monitoring for architectural risk
Supporting operational strategies
Summary
Questions
Practical Security Architecture Designs
Endpoint security
Ransomware
Mitigation
Spyware and adware
Mitigation
Trojan horses
Mitigation
Viruses
Mitigations
Summary
Mail security
The need for email security
Email security best practices
Email security policies
Use of secured exchange servers
User education on security threats
Host-based security tools
Encryption
Securing webmail applications
Email scanners
Email backup
End user security practices
Avoid opening suspicious emails, attachments, or links
Changing passwords
Not sharing passwords
Using spam filters
Avoid logging into emails on public Wi-Fi connections
Avoid sending sensitive information via mail
Email security resources
Microsoft Exchange Server
Sophos PureMessage for Microsoft Exchange
Symantec mail security
Websense email security
Summary
Network security
DDOS attacks
Mitigation
Eavesdropping
Mitigation
Data breaches
Mitigation
Summary
Cloud security
Data breaches
Mitigation
Compromised credentials
Mitigation
Denial of Service
Mitigation
Summary
Bring Your Own Device
Data loss 
Mitigation
Insecure usage
Mitigation
Remote access by malicious parties
Mitigation
Malicious applications
Mitigation
Insider threats
Mitigation
Summary
Internet of Things
Weak authentication/authorization
Mitigation
Insecure interfaces
Mitigation
Lack of encryption
Mitigation
Insufficient configurability
Mitigation
Summary
Summary
Questions
Further reading
Trends in Security Architecture Technology
Border protection
Cloud security
Tokenization
Disaster recovery
VPN
Detection services
Artificial Intelligence
Incident response
Content control services
Spam as a new phishing technique
Identity and Access Management
Increasing use of two factor authentication
Auditing services
Privacy/GDPR
Configuration management
Internet of Things
End point security
New technologies — new breaches
Cryptographic services
Bitcoin and blockchain security
Application security
Applications serving their nation states
Summary
Questions
The Future of Security Architecture
Environmental variables
Political variables
Economic variables
Technical variables
Social variables
Competitive variables
General future associated with security architects
Market consolidations
Breaches and reactions
Secure by design?
Managed Security Service Providers and outsourcers
The evolution of the security tower
The merging of cybersecurity and physical security
Summary
Questions
Assessment
Chapter 1, Security Architecture History and Overview
Chapter 2, Security Governance
Chapter 3, Reference Security Architecture
Chapter 4, Cybersecurity Architecture Strategy
Chapter 5, Program–and Strategy–Level Work Artifacts
Chapter 6, Security Architecture in Waterfall Projects
Chapter 7, Security Architecture Project Delivery Artifacts
Chapter 8, Architecture Design Document
Chapter 9, Security Architecture and Operations
Chapter 10, Practical Security Architecture Designs
Chapter 11, Trends in Security Architecture Technology
Chapter 12, The Future of Security Architecture
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
There has been so much written over the years on the subject of security. IT security. Information security. Cybersecurity. All focused on security. But here's the problem: from a more practical point of view, security is more about quality assurance for your architectures rather than being about ensuring that risks are mitigated.
Most people forget that the core business of an enterprise is business. It's not security in any form. Security—more specifically, cybersecurity—is meant to provide a clear understanding to the business as to what the security risks are and how to potentially mitigate those cybersecurity risks. And that brings us to cybersecurity and how it integrates into architectures.
There are going to be many different types of people—coming from diverse backgrounds—reading this book, but our intent is to focus on the second word in "security architecture", which is architecture. Every architecture should have a focus on security. If you are working on a network architecture, you have to keep in mind things such as security zones and access control lists. If you are putting together an infrastructure architecture, you have to keep in mind what roles the solution will use and how you will harden the various components. And, if you are working on an application architecture, you want to be thinking about how to ensure that the application is designed and coded so that there are as few vulnerabilities in the application as possible.
This book will talk about all the different things that an architect gets involved in and how security is integrated into those activities. There is a heavy slant toward thinking like a security architect, since there isn't much difference between a security architect or any other architect. They all do the same things—they create the same types of artifacts and they support architects in different architecture domains in the same ways. The only difference is the realm of focus.
There are different areas that an architect will focus on, depending on whether they are an enterprise-level architect, a solution-level architect, or a supporting-level architect. And, with each, there are security aspects that have be considered, just as there are aspects that every architect has to think about from other non-security domains. There are governance aspects, strategy and program-level aspects, and solution-level aspects, for instance. Plus, if you are doing your job correctly, you should be interfacing with the biggest stakeholder of them all—the operations teams—since they, too, have to deal with your solution. But they'll have to deal with it long after you are gone.
Enjoy this book and read it for what it's worth. And, hopefully, it will provide you with a view into your own architecture domain and not just into the security architecture domain. Thank you, and we hope this book helps you.
Who this book is for
If you are a security, network, or a system administrator interested in taking up high-level responsibilities, such as designing and implementing complex security structures and modules, then this book is for you. This book is also ideal for non-security architects who want to understand how to integrate security into their solutions.
What this book covers
Chapter 1, Security Architecture History and Overview, gives you an overview of what security architecture covers. This will include a summary of the different layers in security architecture and how they are integrated. This chapter will also talk about the different types of security architects and how what they do differs depending on the needs of the organization. It will also describe the origins of architecture in general, IT/cybersecurity in general, and the evolution of security architecture.
Chapter 2, Security Governance, grants you an understanding of the importance of governance in security generally, as well as in security architecture specifically. The focus will be on how you can't approach security from a personal point of view; rather, an approach that the entire organization agrees to in order to ensure an organization-wide approach to security is required.
Chapter 3, Reference Security Architecture, will give you an actual Reference Security Architecture (RSA) that you can use, as well as an understanding of how to use it and when to use it. The RSA is meant to ensure that the various areas in security architecture are not missed and are included in activities that the architect performs, regardless of what level of architecture is being worked on (whether it's an enterprise-, solution-, or technical-level architecture, for example).
Chapter 4, Cybersecurity Architecture Strategy, talks about the process of creating strategies and roadmaps. This will leverage the information given in the previous chapter and build upon it. It will talk about various inputs into strategies, the development of the SWOT analysis, the requirements of the organization and how they drive strategy, the resulting output of the strategy of specific projects, and a roadmap of delivering those projects.
Chapter 5, Program- and Strategy-Level Work Artifacts, looks at how, at the program and strategy layers, the enterprise security architect has to create a number of things to allow for a communication of the strategy elements to associated stakeholders within the organization, whether it's upward to the executive level or downward to the technical staff. This section talks about these artifacts, what they are used for, and what should be included in each artifact.
Chapter 6, Security Architecture in Waterfall Projects, goes into how the vast majority of organizations out there use a waterfall methodology for delivering their projects. That being so, it's important to first understand the various stages in a project delivery life cycle before you try to understand how a security architect works with those stages. It's also important to remember that a security architect may play two different roles in these phases: a solution architect role for security-specific projects, or a support role to non-security-based projects.
Chapter 7, Security Architecture Project Delivery Artifacts, explains how, since architecture is all about communication, it's important to understand the artifacts that a security architect will work with and deliver in each phase of the project-delivery life cycle. So, to that end, this chapter explores the different phases of that life cycle and some of the artifacts that are associated with them.
Chapter 8, The Architecture Design Document, follows on from the previous chapter, which talked about the various artifacts that are delivered by the security architect in each phase of a project, of which the biggest by far is theArchitecture Design Document (ADD). This chapter focuses just on the ADD and what should go into it. At the end of the day, this document is the core of what the architect does and is used to describe the solution that is to be implemented.
Chapter 9, Security Architecture and Operations, reminds you that security architecture strategies take input from various stakeholders, and so it's important to consider the requirements of the various operations groups. These are stakeholders that not only receive the output of projects but also give input into the creation of new strategies. This chapter discusses this interaction.
Chapter 10, Practical Security Architecture Designs, proceeds from the quite true premise that any organization today needs to assume that they have been compromised. This is not only important for the Security Operations Center (SOC), but also for the cybersecurity architects, so that they are able to build a comprehensive security architecture that can protect, detect, and respond to cyber attacks. By reading this chapter, you will understand the key requirements regarding security for mail, networks, identity, endpoints, BYOD, IoT, and infrastructure, as well as get insights on real-world cyber attacks and design practices.
Chapter 11, Trends in Security Architecture Technology, looks at the trends in various areas with regards to security and what the security architect should be thinking about down the road.
Chapter 12, The Future of Security Architecture, concludes the book by talking about what the future holds for the role of the security architect.
To get the most out of this book
This book is written for those individuals that are designing or architecting IT solutions. The solutions don't necessarily have to be security solutions, but can be for any architecture tower. To get the most out of this book, you should have an understanding of how to architect a solution and the various activities that are involved in the running of an IT organization.
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "That's the reason why the factors for both don't start with 0."
A block of code is set as follows:
html, body, #map { height: 100%; margin: 0; padding: 0}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
[default]exten => s,1,Dial(Zap/1|30)exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)
Any command-line input or output is written as follows:
$ mkdir css
$ cd css
Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
Security Architecture History and Overview
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
The history of architecture
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.
The history of security architecture
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.
Security in network 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.
Security in infrastructure architecture
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.
Security in application architecture
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?
Security in virtual architectures
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.
Security in the cloud
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.
Security architecture
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.
