Securing Systems Applied Security Architecture and Threat Models

Internet attack on computer systems is pervasive. It can take from less than a minute to as much as eight hours for an unprotected machine connected to the Internet to be completely compromised. It is the information security architect’s job to prevent attacks by securing computer systems. This book describes both the process and the practice of assessing a computer system’s existing information security posture. Detailing the time-tested practices of experienced security architects, it explains how to deliver the right security at the right time in the implementation lifecycle. Securing Systems: Applied Security Architecture and Threat Models covers all types of systems, from the simplest applications to complex, enterprise-grade, hybrid cloud architectures. It describes the many factors and prerequisite information that can influence an assessment. The book covers the following key aspects of security analysis: When should the security architect begin the analysis? At what points can a security architect add the most value? What are the activities the architect must execute? How are these activities delivered? What is the set of knowledge domains applied to the analysis? What are the outputs? What are the tips and tricks that make security architecture risk assessment easier? To help you build skill in assessing architectures for security, the book presents six sample assessments. Each assessment examines a different type of system architecture and introduces at least one new pattern for security analysis. The goal is that after you’ve seen a sufficient diversity of architectures, you’ll be able to understand varied architectures and can better see the attack surfaces and prescribe security solutions.

DedicationContentsForeword by John N. StewartForeword by Dr. James F. RansomePreface AcknowledgmentsAbout the Author Part I IntroductionThe Lay of Information Security LandThe Structure of the Book References Introduction Breach! Fix It! Information Security, as Applied to Systems Applying Security to Any SystemReferencesThe Art of Security AssessmentWhy Art and Not Engineering? Introducing "The Process" Necessary IngredientsThe Threat LandscapeWho Are These Attackers? Why Do They Want to Attack My System?How Much Risk to Tolerate?Getting StartedReferencesSecurity Architecture of SystemsWhy Is Enterprise Architecture Important?The "Security" in "Architecture"Diagramming For Security Analysis Seeing and Applying PatternsSystem Architecture Diagrams and Protocol Interchange Flows (Data Flow Diagrams)Security Touches All DomainsComponent ViewsWhat’s Important?What Is "Architecturally Interesting"?Understanding the Architecture of a SystemSize Really Does MatterApplying Principles and Patterns to Specific DesignsPrinciples, But Not Solely PrinciplesSummaryReferencesInformation Security RiskRating with Incomplete InformationGut Feeling and Mental ArithmeticReal-World CalculationPersonal Security PostureJust Because It Might Be Bad, Is It?The Components of RiskThreatExposureVulnerability ImpactBusiness Impact Data Sensitivity Scales Risk AudiencesThe Risk OwnerDesired Security PostureSummaryReferences Prepare for AssessmentProcess ReviewCredible Attack VectorsApplying ATASMArchitecture and Artifacts Understand the Logical and Component Architecture of the SystemUnderstand Every Communication Flow and Any Valuable Data Wherever Stored Threat EnumerationList All the Possible Threat Agents for This Type of SystemList the Typical Attack Methods of the Threat Agents List the System-Level Objectives of Threat Agents Using Their Attack Methods Attack SurfacesDecompose (factor) the Architecture to a Level That Exposes Every Possible Attack SurfaceFilter Out Threat Agents Who Have No Attack Surfaces Exposed to Their Typical Methods List All Existing Security Controls for Each Attack SurfaceFilter Out All Attack Surfaces for Which There Is Sufficient Existing Protection Data SensitivityA Few Additional Thoughts on Risk Possible ControlsApply New Security Controls to the Set of Attack Services for Which There Isn’t Sufficient MitigationBuild a Defense-in-Depth SummaryReferencesPart I SummaryPart II IntroductionPracticing with Sample AssessmentsStart with ArchitectureA Few Comments about Playing Well with OthersUnderstand the Big Picture and the ContextGetting Back to BasicsReferenceseCommerce WebsiteDecompose the SystemThe Right Level of DecompositionFinding Attack Surfaces to Build the Threat Model RequirementsEnterprise Architecture Enterprise Architecture Pre-work: Digital Diskus Digital Diskus’ Threat LandscapeConceptual Security Architecture Enterprise Security Architecture Imperatives and Requirements Digital Diskus’ Component ArchitectureEnterprise Architecture Requirements ReferencesBusiness Analytics ArchitectureThreatsAttack Surfaces Attack Surface Enumeration MitigationsAdministrative Controls Enterprise Identity Systems (Authentication and Authorization) RequirementsReferencesEndpoint Anti-malwareA Deployment Model LensAnalysisMore on Deployment ModelEndpoint AV Software Security RequirementsReferencesMobile Security Software with Cloud ManagementBasic Mobile Security ArchitectureMobility Often Implies Client/CloudIntroducing CloudsAuthentication Is Not a PanaceaThe Entire Message Stack Is ImportantJust Good Enough SecurityAdditional Security Requirements for a Mobile and Cloud ArchitectureCloud Software as a Service (SaaS)What’s So Special about Clouds?Analysis: Peel the OnionFreemium DemographicsProtecting Cloud SecretsThe Application Is a Defense"Globality"Additional Requirements for the SaaS Reputation Service 319References Part II Summary Part III Introduction Patterns and Governance Deliver Economies of ScaleExpressing Security RequirementsExpressing Security Requirements to Enable Who Consumes Requirements?Getting Security Requirements ImplementedWhy Do Good Requirements Go Bad?Some Thoughts on GovernanceSummaryReferencesBuilding an Assessment ProgramBuilding a ProgramSenior Management’s JobBottom Up?Use Peer NetworksBuilding a TeamTrainingDocumentation and ArtifactsPeer ReviewWorkloadMistakes and MisstepsNot Everyone Should Become an ArchitectStandards Can’t Be Applied RigidlyOne Size Does Not Fit All, ReduxDon’t Issue Edicts Unless Certain of ComplianceMeasuring SuccessInvitations Are Good! Establish BaselinesSummaryReferencesPart III Summary and AfterwordSummaryAfterwordIndex

Brook S.E. Schoenfield is Director of Product Security Architecture at Intel Security Group. He is the senior technical leader for software security across the division’s broad product portfolio. He has held leadership security architecture positions at high-tech companies for many years. Brook has presented at conferences such as RSA, BSIMM, and SANS What Works Summits on subjects within security architecture, including architecture risk assessment and threat models, information security risk, SaaS/Cloud security, and Agile security. He has been published by CRC Press, SANS, Cisco, and the IEEE.