Hands-On Cybersecurity for Architects

Description

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.