[ Pobierz całość w formacie PDF ]
.×%Wherever possible, architectural components should be acquired and not built inhouse.This principle reflects the fact that expertise of The Secure Bank isin financial services, not in the development of secure software.×%The security architecture should combine components in such a way that theymutually reinforce each other, thereby achieving defense in depth.The objec-tive of this design principle is to minimize critical dependencies on indi-vidual components and to foresee multiple lines of defense in responseto particular threats.×%Where appropriate, software from multiple vendors should be deployed toreduce the risk associated with vendor-specific vulnerabilities.Using morethan one vendor solution to implement a security service decreases therisk of falling foul to a little-known vulnerability.×%The implementation of security services should not result in an unacceptableperformance bottleneck for business services.In other words, the businesscomes first.The key word in this phrase is unacceptable.In reality,should this situation occur, other alternatives would be researched.Inan extreme situation, the business would be given the option of sign-ing off the risk.The corresponding service could still, of course, beimplemented by specific applications.8.4.3 Modeling the IT infrastructureThe purpose of the modeling exercise is to reduce the complexity ofthe problem by emphasizing network and system characteristics that areimportant from an IT security viewpoint.In order to do this, we construct ahigh-level model of the infrastructure consisting of the following threecomponents:1.A decomposition of the IT infrastructure into zones with similarsecurity requirements;2.A description of what type of system is present in which zone;3.A matrix summarizing important data flows between zones.TLFeBOOK 188 Building an IT security architectureThe major advantage of defining zones is that it simplifies the dialoguewith management because problems that need to be resolved in one zoneneed not necessarily affect other security zones.Zones should be chosen togroup together systems with similar security requirements.Following thisphilosophy, an analysis of the internal structure of The Secure Bank indi-cates the existence of ten security zones (see Figure 8.2).Each zone covers agroup of systems or network technologies that are likely to have similarsecurity requirements.Defining zones 1 and 2 was simple in this case, as both executive man-agement and the internal audit department had internal servers dedicatedto their own use.Although the two departments happen to share a commonLAN segment, to all extents and purposes, they are operating independentlyand share little data.When the audit department has data that is of interestto the executive management team, it is released as an audit report.In cer-tain circumstances, both departments have a reasonable requirement to seedata belonging to the other party, but this should occur as a result of anorganized process, not haphazard access.It therefore makes sense to modelthis as two separate zones.Zone 3 groups together departments on the basis of the data they access.All of the departments in zone 3 require extensive access to customer data,albeit for different reasons.The organization department needs to accesscustomer data in order to carry out studies related to internal efficiency andto analyze customer satisfaction reports.Zone 4 is the production environment and contains all shared resources,including the definitive source of all production data and applications.Pro-duction data that is held on departmental servers is taken from the produc-tion systems, through the use of either a batch-oriented process or real-timedata transfer.As it contains the master copy of all production data, the secu-rity of zone 4 is critical to the success of the bank.On the other hand, zone 5 contains no production data, or it shouldn t atleast, as this zone covers the development LAN.Unfortunately, in order tocarry out certain types of tests, the development teams have stated the needto access production data.This request cannot be ignored and complicatesthe process of securing this zone.Zone 6 encompasses all connectivity infrastructures that are not con-nected to the Internet, and zone 7 includes all Internet-connected devices.This distinction is made for historical reasons, as the bank has already imple-mented an Internet connection to an isolated network segment within theenterprise.Personnel working in branch offices do not currently have Inter-net access.Zone 8 is the branch office environment.This includes a local serverhousing data on branch clients and workstations.The server updates thecentral site and receives updates from the latter via a nightly exchange offormatted files.Zones 9 and 10 cover all external network infrastructure.Zone 9includes all networks provided by commercial third parties, and zone 10covers the Internet.TLFeBOOK Z7 Z10HeadquartersInternetBranch officeZ8Z1 Z2ExecutiveAuditmanagementZ6 Z9Payments, personnelMarketing, organizationdealing roomIntranetOtherAccounts, credit,financialZ3branch networkinstitutionsProduction Z4&.PSTNNASDevelopment Z5&.Figure 8.2 The Secure Bank security zones.TLFeBOOK8.4The design phase189 190 Building an IT security architectureOnce we have defined the security zones, we aim to identify the differ-ent types of system present in the interior of each zone.The idea is to clas-sify these systems based on their high-level security requirements.Thisrequires judgment, as the goal is not to carry out a detailed risk assessmentagainst these systems (this is the next step).Here, we are trying to furthersimplify the model of the IT infrastructure by defining a limited number ofclasses of systems against which we can perform such a risk analysis.Table 8.1 shows the classes of systems identified within each securityzone at The Secure Bank.Finally, we examine existing flows of data between zones, concentratingon the most important flows.Although these may not be formalized, theydo exist and can be helpful in defining network segregation rules and trustrelationships during a later phase.The important flows for The Secure Bankare summarized in Table 8.2
[ Pobierz całość w formacie PDF ]