WIXLIB

Security Reference Architecture–IntroductionA MATURITY MODEL FORCRITICAL SYSTEMS AND ENDPOINT SECURITYMany security programs now recognize the importance of using a maturity model specific to particularareas of security. Systems that are most importantto the organization need to receive a heightened levelattentionSecuritycomparedto a commonend-user laptop.The SANSofEndpointMaturityModel (CONTINUED)Critical systems are a smaller but more highly sensitive set of systems compared to the broader set ofLevel 5: Proactive, Comprehensive, Continuous and Measurabledevices—endpoints—which can be broadly defined asAt this pinnacle level, the organization has a model security program around all itsevery device or system that connects to the organizaendpoints and user endpoints, designed and executed to anticipate change. It is alignedtion’stechnologyinfrastructure.withIT, procurementand businessrisk. It accurately identifies and protects all criticalns nurture awherein allr security to.ROGRAMbusiness processes, information and assets related to endpoints. Security policies odelson an intranet,andcriticalall affected usersare requiredto readrelevantpoliciesannually.All endpointinfrastructurecomponentsare monitoredmodelshavebeensecuritydevelopedandare seeinggreateruse because many organizations perceive the guidance from traditional security maturity models to beand law enforcement. If applicable, the organization participates actively with thetoo broador generictoAnalysisadequatelyaddress endpointappropriateInformationSharing ated toAll endpoint information is classified and labeled, and critical endpoint assets aredevelopthe SANSSecurityMaturityModelphysicallysegmentedto isolate Endpointthe most sensitivematerial. Dataloss preventionto LP)technologyis in place, and anygaugeencryptedthecommunicationswith outsideissecurityproxied so thatcontent may withbe inspected.Endpointssecurity.are locked downso thatprogramendpointThemodelno unauthorized software can run (whitelisting), and the network is configured todefines five levels of maturity based on measureautomatically reject any device not authorized, disabling the port and sending an alertments of six different dimensions, called elements.to operations staff. Users are fully aware of their security responsibilities; regular trainingcontinuously, initial responses to incidents are fully automated, and security leadershiphas established close coordination with Computer Emergency Response Teams (CERTs)and inoculation result in nearly zero user-error security incidents.LEVEL 1Random, orDisorganizedLEVEL 2Reactive,or TacticalLEVEL 3PreventativeLEVEL 4Organized,or DirectedLEVEL 5Proactive,Comprehensive,Continuous andMeasurableWhen selecting a security maturity model, you mayneed to include a separate model to help you gaugeand improve the effectiveness of your security program in securing the organization’s endpoints.TRIPWIRE’S REFERENCE ARCHITECTURE ANDTHE C2M2 MATURITY MODELThis reference architecture sets relate back to maturity levels defined in C2M2. The architecture helpsplace each security control into its appropriate C2M2domain, defining what levels of maturity you canexpect by implementing the reference architecturefor a given control, and differentiating between thevarious levels by what technologies, processes orpeople are in place. The reference architecture further defines appropriate MILs for the controls provided by Tripwire products, augmenting the generaldefinitions of the MILs with more specific guidance.DEVELOPING ASECURITY ARCHITECTUREWhile a security framework provides a broad view ofthe many different security controls an organizationmay need to deploy and manage; you shouldn’t viewit as a checklist of 149 controls that you can implement one by one until you are finished and secure. Inthe past, a checklist approach may have been moreappropriate, but security has evolved. Organizationsused to have a “defense in depth strategy,” withnumerous independently deployed security controlsthat provided layers of protection. Today, securityis more of an interconnected web of controls thatcommunicate with each other and adapt dynamicallybased on changing intelligence and needs.Fig. 1: The SANSEndpoint Security Maturity Model CurveFigure 2. Endpoint Security Maturity Model Curve9MIL0: Notaccomplishingobjectives, oraccomplishing withmanual processDetecting a Targeted Data Breach with EaseMIL1: Accomplishingobjectives, but withsome automation,but minimal or adhoc processMIL2: Establishedand followedstandard operatingprocedures, moreautomationMIL3: Matureimplementationwith high degree ofautomation andhighly optimizedFig. 2: The Cybersecurity Capability Maturity Model (C2M2) maturity indicator levels (MILs)TRIPWIRE PRESCRIPTIVE GUIDE TO A SECURITY REFERENCE ARCHITECTURE 5

confidence in its ability to sustain the performance of the practices over time and acrossthe organization.3.2.3 Summary of MIL CharacteristicsTable 3 summarizes the characteristics of each MIL. At MIL2 and MIL3, the characteristicassociated with the approach progression is distinguished from the characteristics associatedwith the institutionalization progression.Table 3: Summary of Maturity Indicator Level sPractices are not performedInitial practices are performed but may be ad hocInstitutionalization characteristics:Practices are documentedStakeholders are identified and involvedAdequate resources are provided to support the processStandards or guidelines are used to guide practice implementationApproach characteristic:Practices are more complete or advanced than at MIL1Institutionalization characteristics:Activities are guided by policy (or other directives) and governancePolicies include compliance requirements for specified standards or guidelinesActivities are periodically reviewed for conformance to policyResponsibility and authority for practices are assigned to personnelPersonnel performing the practice have adequate skills and knowledgeApproach characteristic:Practices are more complete or advanced than at MIL2Fig. 3: Generic characteristics of each Maturity Indicator Leveldefined in C2M2To better understand this evolution, consider thisexample: In the past, a network firewall and a fileintegrity monitoring system on a server had nothing in common other than they were both providingsecurity to an organization. Network and systemsecurity were considered very different practices,and although both were important, they barely overlapped. Because they were so different, building adeployment architecture for a firewall was unlikely toeven consider what security controls were in place onservers, other than perhaps what ports and protocolsthey would need to communicate over for management purposes.Contrast that to the way these controls are beingdeployed today. Next-generation firewalls now connect to threat intelligence services that provideupdated rules designed to block the command andcontrol of infected endpoint systems. These rulesare developed based on dynamic analysis of malicious code that’s been delivered to sandbox analysissystems.With the example above, a security reference architecture can help you coordinate the detection andreal-time delivery of a potentially malicious executable for analysis from a critical server to a malwareanalytics service. That service can then create blocking rules on an organization’s external firewall, whichmay block a successful malicious code insertionfrom being used to pivot to additional systems orexfiltrate data. That’s the connection and coordination of three separate security controls—a networkfirewall, a malware sandbox analysis service, and anendpoint detection and response system.6 TRIPWIRE PRESCRIPTIVE GUIDE TO A SECURITY REFERENCE ARCHITECTUREThe now interconnected nature of security controlsrequires you to architect security solutions together.A security reference architecture can help you definehow to implement your controls so that they form thisinterconnected and coordinated web of controls.CONSIDERATIONS WHEN SELECTINGSECURITY CONTROL SOLUTIONSWhile it would be wonderful if you could simply buyall 149 security controls from a single vendor andhave them all work together, that’s just not reality.Ironically, the vendors that have accumulated thelargest number of controls tend to do the worst jobof actually integrating them. In addition, some of thelargest security vendors in times past have recentlybeen the most active in end of life-ing and divestingproducts.That said, you probably don’t want to buy13your 149 controls from 149 different security vendors,either.Selecting the right vendors is important in developing a successful architecture. Maintaining a coreset of trusted strategic vendors that have articulated a well-defined framework, and demonstratedboth commitment and execution on integration andinteroperability with other security control vendors isthe best approach here.The ideal architecture for a security control is a complete, well-documented, and open API, with pre-builtintegrations with many partners. This allows for theconnectivity between security controls required bytoday’s approach to security. Unfortunately, thesecharacteristics tend to be present only in controlsbuilt on aggregating data from other systems. Whenchoosing a solution for a security control, identify themost important integration points in the architecturefor that control and determine if the solution has thecapability for those specific integrations.THE TRIPWIRE REFERENCE ARCHITECTURE SETYou can apply a model for security architecture tomultiple layers of security and at different levels ofabstraction. Tripwire’s reference architecture provides details at two levels:»Level»1: Systems security reference architecture,which describes the inter-related controls of anentire framework as it relates to systems security. This is complementary to other architecturesthat focus on network security.

Security Reference Architecture–Introduction»Level»2: Specific security controls referencearchitecture, which describes the architecture forthe individual controls offered by Tripwire.Our reference architecture set excludes other areaswhere reference architectures are also important.For example, the set excludes the areas of networkand application security and the myriad security controls outside of the scope of Tripwire’s offerings.Note that systems security is a broad area that covers multiple security controls. It includes controlsoffered by Tripwire, such as file integrity monitoring, security configuration management, vulnerability management and log management. But it alsoincludes additional controls from Tripwire partnersand others in the market, such as antivirus/antimalware, identity and access management, assetmanagement, deployment management, remotemanagement, patch management, email filtering,browser protection, exploit prevention and disasterrecovery.PRIORITIZING SECURITYINVESTMENTS AND EFFORTSWhen selecting security controls, you must first takethe time to identify which controls to use for all yourdifferent types of assets. This takes significant effortand thought. In addition, you must prioritize and balance the following three competing strategies acrossthis complete control set—perhaps an even greaterchallenge:»Depth»of coverage: Make additional use of thecontrols already in place on the assets alreadycovered»Breadth»of coverage: Deploy controls already inuse on additional assets not currently covered»Broaden»control set: Deploy new controls notcurrently in use on some assetsPerhaps the most logical way to determine whichcontrols to use and where involves taking a riskbased approach to prioritizing new security projects.This approach makes that determination by forecasting the impact a new project may have on reducingrisk and seeking to maximize that impact. In reality,almost any legitimate security control will reducerisk, and the sheer number of defined controls makeit impractical to fully evaluate the benefits of eachoption, so establishing these priorities can presentmany difficult decisions.CRITERIA FOR SECURITY CONTROLS DESCRIBED BYTHE TRIPWIRE REFERENCE ARCHITECTURETripwire’s reference architecture first distills all thepossible systems security controls you could deployinto a smaller set that meets the following criteria:Security is the control’s primary function. Some controls like disaster recovery may be critical to security, but serve their primary function in a broader IToperations use case. Such controls would fit into anIT operations reference architecture, and while noless important, are not included here.Security of the individual system the control interacts with is its primary function. Some controls maycombine network-based protections with individualsystem tools. For example, web filtering may be primarily done with a network proxy, but have a systemcomponent available for mobile and remote workersas well. The Tripwire reference architecture excludessuch a control because it would typically be found ina network security reference architecture.The resulting list of system security controls thatmeet these criteria include antivirus/anti-malware,exploit prevention, file/system integrity monitoring,identity and access management, log management,security configuration management and vulnerabilitymanagement.Figure 4 shows the systems to be addressed inthe Tripwire reference architecture based on bothnumbers of the type of asset and importance of theasset to the organization. Not surprisingly, endpointsconstitute the most numerous systems, but havethe lowest value. Infrastructure sits in the middle,and critical systems, while the least in number,rank highest in importance for an organization.Critical systems include both IT systems as well asoperational technology systems that run the physicaloperations of a company.While you can allocate all of your security investmentto the top of the pyramid to protect the crown jewelsat all costs, that leaves the majority of the organization at the base of the pyramid completely insecure.Finding the right balance of investment is the challenge, but the pyramid figure shows that investmentlevels should be higher at the top and relatively lowat the bottom, on a per asset basis.This suggests that for the critical systems, all themajor security controls are on plan to be implemented, but some controls may be omitted for endpoints,TRIPWIRE PRESCRIPTIVE GUIDE TO A SECURITY REFERENCE ARCHITECTURE 7

particularly those that require significant humaneffort to make work operationally. You should construct a more detailed implementation order basedon their prioritization with regards to the set of allcritical assets—for example, your payment systemsmay be most critical so you would invest more insecuring them sooner than you would in protectingyour less, but still critical, assets.Figure 5 shows how you can allocate systems security controls based on risk. Higher-risk systems inheritthe controls from lower risk systems, then add further security controls appropriate for those assets.KEY TAKEAWAYSAt this point, you should understand the importanceof, and have guidance on, selecting a security framework for creating your reference architecture. Youshould also recognize the value of selecting a security maturity model and have guidance on makingthat choice as well.In addition, you should realize that treating a securityframework as a checklist does not work with today’ssecurity that relies on an interconnected and coordinated web of security controls. Developing a resilientsystem for today’s security environment benefitsgreatly from use of a security systems referencearchitecture that spells out at a high level how eachcontrol connects with other controls and systems.Your system also benefits from a security controlsreference architecture that takes an in-depth look ateach control and its role in the overall systems security architecture.Finally, you should understand the challenges you’llface when prioritizing your security investmentsand possible approaches, such as a risk-basedapproach, that can aid you in meeting this challenge.Prioritization helps you identify the controls you willfocus on first when applying your security systemsand security controls reference architecture sets.Critical SystemControls Integrity Monitoring -—Change Auditing Mid-level ControlsEndpoint Controls Vulnerability Management Antivirus/Anti-Malware Exploit Prevention Identity & Access Endpoint Detection and Response EncryptionPatch ManagementFig. 4: Pyramid of asset count and value8 TRIPWIRE PRESCRIPTIVE GUIDE TO A SECURITY REFERENCE ARCHITECTUREFig. 5: Sample set of system controls allocated by risk

Security Reference Architecture–Part TwoPART TWO:A REFERENCE ARCHITECTURE FORFILE & SYSTEM INTEGRITY MONITORINGIn Part 1 you learned important background

and business systems, deployment architecture dia-grams, and many other important details and consid - erations related to the control Although the reference architecture at the secu-rity control level is based on Tripwire solutions, your overall strategy must address the other controls o