Copyright 2003 Information Systems Audit and Control Association. All rights reserved. www.isaca.org.

Security Architecture: One Practitioners View

By Tim Scammell, CISA, CA
Abstract
The security architect is a key function within many corporations, or at least it should be. This role could function as a corporate clutch, providing an interface between the security policymakers and those tasked with providing information systems (IS) solutions to businesses. Such a role needs to balance the demands of the policy setters against the implementation barriers (available technology, integration and cost barriers) facing the IT department and derive a solution that is costeffective, yet meets business requirements. This balancing act falls short of being a science and demands the application of a wide range of tools and techniques, both technical and personal. This article takes one practitioners experiences and explains the techniques found to be effective. can play, the methodologies available and the way that this role would interact with other parts of the IT and IS security organisation. Space limitations prevent me from doing this here. This article has been divided in half. The first half of the document describes some of the key issues facing the security architect (SecArch), while the second describes tools I have found valuable.

Stating the Problem

Security Dilemma Security is without doubt a key requirement for any modern company,1 especially for those in the financial sector or those involved in medical or health-related matters.2 However, other companies also are reliant on IS security to protect key assets, intellectual properties or even major distribution channels (e.g., Internet). Thus, security is used in many cases to protect a companys competitive advantage, maintain confidentiality, satisfy regulators and develop a sound customer relationship. However, I would suggest that the outcome of many IS security initiatives is not limited to these objectives. Regrettably, many of our contemporaries (especially those within IT) view security as an obstacle to realising their own objectives. IT and business alike often find themselves frustrated by a growing number of policies and procedures that limit their perceived flexibility and seem to inflate the cost of their deliverables. This, in turn, breeds apprehension regarding security and makes it difficult to design and develop the support needed to implement effective IS security. In more extreme examples, security can become a political tool, wielded to satisfy personal objectives. Using hype and fear tactics, the business is unwillingly forced to make decisions on issues that are not fully understood and, therefore, cannot be challenged successfully. Such an approach entrenches corporate cynicism towards IS security and can substantially reduce the effectiveness of the security team. Unfortunately both situations are all too common and are experienced by many. We find ourselves struggling to deliver a secure environment to cynical end users who lack an understanding of why the policies and strategies are in place and who, therefore, do not value the work we perform. However, the dilemma is that without the efforts of the security teams, many companies would be exposed to considerable damages and losses due to security weaknesses. I believe that in many instances the root problem may be the difficulty of trying to communicate to businesses the need for appropriate levels of security in nonemotional terms. It may be a simplistic view, but unless the need for security can be conveyed to businesses in terms they understand, the chances of receiving their support for a security initiative are reduced significantly.

Introduction
After 10 years of auditing and consulting in IS security, I decided to leave one of the big five firms and move to a major Swiss bank. The interviews were exacting and I was fortunate to find myself appointed the security architect of a dot-com start-up. The dot-com was a new subsidiary of the bank with meteoric expectations and deadlines at every turn. However, on being welcomed onto the small international team, I asked the single question, What do you want me to tackle first? The head IS architect turned and simply said, Everything. This was my first challenge as a security architect. I had no job description, and curiously had never encountered such a position within other organisations with which I had worked. I suspect that this situation arose because IS security typically is polarised between policymakers and engineers, and the role of security architect represents a compromise between these two extremes. Thus, I tried to establish what a security architect should do within a rapidly evolving financial services company, but the economic downturn led to the subsequent abandonment of the dot-com venture. However, I continued to act as a security architect within the parent company and have worked in corporate head office. And now, I find myself within a semiautonomous business unit. Each position has presented a unique set of challenges, and provided opportunities to identify the skills needed to be a security architect. In this article, I wish to share my skills and experiences, and I hope to energise debate over the role and function of a security architect. The skills presented are neither unique nor novel, but are pragmatic and have proven to be valuable in a range of circumstances. I hope that they provide insight as to how a security architect can be instrumental in developing a cost-effective, end-to-end IS security environment. It is clear that the security architect works to design an acceptable IS security environment for an organisation. Such a discussion would need to identify the role that this individual

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 1, 2003

A Problem of Ownership In this environment, we introduce the SecArch.3 Generally, this position is a part of the IT department and reports through this organisation, often with only dotted line reporting responsibilities to the existing IS security teams. The SecArch also is often distant from the development and engineering teams who generally report, through other channels, to the CIO. The ultimate result is that this position often is unable to make decisions directly, but can only influence others. This illustrates a classic case of responsibility with insufficient or inadequate authority. However, the SecArch generally will be part of a team that has the responsibility of designing a stable and cost-effective information systems environment that will meet current and future business requirements. Yet with all these responsibilities, the SecArch does not own any of the infrastructure and often cannot make decisions that bind the system owners. Role of Governance Given the lack of ownership, the success that IS architecture (in general) will achieve may be highly dependent on the IT governance model. This view is echoed by many commentators who believe that effective architecture governance is a key prerequisite for IT strategic effectiveness.4 However, many companies lack governance structures that help release sound IS architectures, and as a consequence, SecArchs need to carefully consider the relationship they have with their respective partners. Reporting lines, geography, language and focus (e.g., tactical vs. strategic) all create barriers that weaken the effectiveness of existing governance models and, therefore, impact your ability as a SecArch to create a sound security framework. Points to Consider
A SecArch would normally include consideration of the following points when analysing a possible solution: The level of security provided by a solutionScalability Comprehensiveness of what is being discussedFlexibility Fit within current environmentMaintainability Impact on future strategySupportability Compliance with policy and regulatory requirements Manageability Risks created and mitigatedRecoverability Cost to implement and maintain Ongoing governance and support infrastructures

and would have failed even the most superficial review. My arrival in the company served to stimulate the needed growth in this area, but this activity had to be performed within the tightest of constraints. The policy environment was given (i.e., from the holding company), the regulatory environment was given (i.e., by the central banks of the countries in which we were operating), operational procedures were almost complete and applications teams were struggling to deliver the first release into production. Thus, the challenge was how to introduce a sound security architecture with one foot effectively nailed to the floor. In this case, the governance framework favoured the architects, but exercising this authority would only have jeopardised our relationship with the already stressed development team. Understanding the Obligations Other entities might not have these challenges, but SecArchs need to understand the limitations facing them. Legal requirements typically represent immovable barriers, yet ones that the business understands and accepts. Corporate policies (especially security policies) often are more exacting and, while necessary, are not always compelling for the business. If you doubt this, try asking the business to fund a multimillion Euro (or dollar) project solely to satisfy a policy requirement. This is definitely not something for the faint-hearted, and success will depend more on the merits of your argument than the contents of the policy. I also have found that policies generally are written for established companies and almost always by staff sitting within a head office department. While generally useful to a growing business, or smaller (regional) departments, these same security policies also can be dangerous. For these smaller entities, policies impose costs where tight financial control is essential for survival and demand rigidity where flexibility is essential. This is not an argument against policies, but it is an acknowledgment that architects are faced with limitations preventing them from implementing their ideal vision of security. Some of these limitations are real, some illusionary. Some will help business, and others will hamper it. To deliver a security architecture that is cost-effective, practical and at an appropriate level, SecArchs need to truly understand all limitations within which they must work, not just those with which they are immediately confronted. Summary of the Problem These few comments highlight that the SecArch has a demanding role and is faced with a number of challenges. The challenges are not insurmountable, but will be heavily influenced by: The manner in which security has been positioned within the enterprise. Do your developers view security as an arbitrary burden or a necessary evil? Whether the SecArch is a decision-maker or merely part of a group seeking to influence the decisions made by others The limitations preventing the implementation of model security solutions. Real limitations need to be identified and adhered to strictly, but only when correctly balanced against real business pressures. In the second part of this article, I will discuss approaches that might overcome these problems, thereby enhancing the effectiveness of the SecArch.

One Foot Nailed to the Floor Even with the best governance model, the SecArch does not operate in a vacuum. If this were possible, many security issues would be avoided. However, every successive IT-related decision imposes continually greater limitations on the architect. These limitations force the SecArch to make greater and greater compromises, which often degrade the quality of the final solution. Parent company policies, legal requirements, local skill sets and vendor support idiosyncrasies represent common limitations and, in many instances, are unavoidable. My experience is that within 12 months of founding the dotcom, all major architectural decisions had been made. Unfortunately, the security environment largely was underdeveloped. A minimum set of controls existed, but these were lacking

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 1, 2003

Solving the Problems

Overall Concept There are numerous ways that a SecArch could address the issues and deliver a high-quality and successful contribution to the company. This article does not attempt to illustrate all the ways this could be done, but describes one way it has been done. While success has varied on occasion, generally the following tools and techniques have helped me deliver value to our business, and hopefully they have the same potential for yours. Frameworks Available There are a number of frameworks available to help SecArchs direct their work. The most popular are the Zachmann model and index framework.5 These models are key tools in the creation of an architecture framework, but curiously they do not universally mention security as a key requirement. These models appear to view security as a component that quite often is associated primarily with the management of access privileges. Access controls are obviously important, but they are less relevant to the SecArch when compared with issues such as designing a solution that is scalable, cost-effective and with strong risk mitigation characteristics. In designing security measures, SecArchs need to consider the importance of the topics within the architectural framework used by their organisation. Where security is not considered a crossdomain activity, I would advocate amending the framework to accommodate this view. Changes to such a framework need to be performed in accordance with your needs and requirements but without disturbing the integrity of the model. Some may view such changes as a corruption of the methodology, but I would suggest that such a departure is warranted where security considerations are not adequately weighted across all aspects of the IS architecture and, therefore, possibly underemphasized. Avoiding Product Focus Too often, I have sat through architecture-related meetings where most of the time was spent in a heated debate over the product to be used. This is not time wasted, as product selection is a valid issue and one of critical importance to the success of the initiative. However, this is not an issue that should require the SecArchs involvement. This may engender a reaction from many, but the question is whether the exact product is important in specifying a security architecture. I would suggest that it is generally not critical, as these points render themselves insignificant when compared, for example, to the importance of interoperability and conformity with standards. Indeed, abstracting away from products altogether maintains the integrity of the architecture and provides the flexibility that many multinational companies need to operate. While vendor discounts and loyalty might be sacrificed in some cases, the viability of the architecture in multiple geographic locations will not be jeopardised, due to IT teams that deploy the architecture using their knowledge of local vendor and support issues. Through the maintenance of a product-independent stance, it also is possible that SecArchs ability to achieve their strategic goals will be enhanced. For example, they will not get drawn into the inevitable product wars, where rival camps argue over vendors and platforms (e.g., the perennial UNIX, Windows or Mainframe question). It also provides neutral

input into business case and risk assessment activities, again keeping the architecture pure and free from controversy that will breed resistance and slow the adoption of your desired architecture Steering the End Result I work with dynamic architects in another business unit who perform excellent work and are constantly generating valuable ideas and concepts. Despite their professionalism, this team is frustrated regularly by other parts of the same IS organisation. What characterises this situation is that the architectural involvement concludes soon after they publish their designs. This situation has no culprit or villain as the corporate governance model clearly delineates among the responsibilities of the architecture, engineering and operational departments. However, as soon as a concept leaves the hands of the architects, budget, time and resources limitations all simultaneously attack the solution and the result is seldom what was envisioned by the architects. The result becomes a patchwork of solutions that is neither truly strategic nor tactical. These solutions seldom are sufficient and require considerable subsequent efforts before they meet the original specification. If you find yourself in a similar situation, you have my sincerest sympathies, but there is hope. What has proven effective within my organisation is for the architecture teams to add project management skills to the services they provide. This approach modifies the role played by the SecArch and requires significant investments of time, but has allowed the SecArch to actively participate in projects and even lead some initiatives. Project management is not generally the core competence of the security architecture team, but through judicial use of this skill, the team has been able to ensure that key architectural components are delivered as originally envisioned. Any deviation from initial requirements can be managed actively, with compensating controls or infrastructure introduced in a manner that minimises risk. Such a commitment will increase the workload of the architecture team members and mandate their proficiency in project management. Neither task is insurmountable, but both represent a new challenge that needs to be overcome.6 If successful, then the involvement of the architecture team in infrastructure delivery can be one of the easiest ways to accomplish the goals of the SecArch. Consistency in Documentation This is not a trivial topic, as the importance you place on documentation could determine the success of your security architecture.7 I have worked on a team where one staff resource was occupied full time with simply completing and updating architectural documentation. This was a huge drain on our team and represented almost 20 percent of our total budget. However, without this commitment, our documentation would have been dated, become obsolete and led to poor decisions and inevitable reworkingpossibly not by the architecture team but by our clients, the development teams. The cost in reputation and credibility would have been considerably more than the 20 percent spent to avoid this fate. I consider this to have been a wise investment, given our circumstances, and a future best practice.

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 1, 2003

Despite an acknowledged need to maintain good documentation, the difficulties involved in preparing and maintaining this material are comparable to urban legends. Architectural documentation quickly grows to hundreds of pages, morphs into enormous PowerPoint files and generates labyrinthine Visio diagrams. These are my experiences and I openly admit that there must be a better way of doing this, but sadly, few practical examples seem to exist.8 However, documentation is a key deliverable of the architecture team, and this needs a structured and predictable approach that is consistent across the entire entity and one that can be maintained over time with the least amount of effort. The need to create a consistent set of maintainable architectural blueprints is beyond question and the techniques chosen ultimately will reflect your requirements and the complexity of the environment. However, one aspect that I found to be contentious is the availability of the security architecture documentation. Some view these documents as secret and protect them, while others make them available on intranets and even as published excerpts on the Internet. Not surprisingly, I favour a middle ground, where subsets of the documentation (those relating to development processes and requirements) are published on the most convenient medium (e.g., intranet). The more technical and, therefore, more sensitive elements should be kept under more careful control. However, this is a compromise between the awareness of requirements and secrecy that too often breeds ignorance of the target architecture. Risk Assessment I am a great advocate of risk assessments.9 When performed correctly, these tools help strip a problem of unnecessary complexity and focus attention on achieving the best result for the entity as a whole. This is particularly important where complex IT problems need to be analysed and an architecture proposed that could have a significant impact on the business. As it is not always easy to conclude when the business could be impacted, especially within multinational companies, a risk assessment should be part of any security architecture10 initiative. Despite my preference, it is clear that risk assessments are blunt tools and need to be integrated into wider risk management frameworks to provide a single view of the IS security environment. This creates additional effort, but the dividend is a clear foundation upon which to base architecture decisions and track the ramification of decisions within related areas, such as infrastructure or networks. I have found that the use of risk assessments within the architecture planning process helps deliver a more responsive architecture that avoids obsolescence and is aligned to business needs.11 Importance of the Business Case While the risk assessment is important, I believe that the business case is by far the best tool available to the SecArch. It is a difficult weapon to wield and often difficult to aim in the desired direction. However, it is still beneficial as it: Speaks the language of business management Provides a forum to translate risks into costs Provides an avenue to continually develop architecture Focuses the architecture team on delivering cost-effective pragmatic solutions

Ironically, these benefits may be the same reasons why many architects prefer not to use this tool. Their view is that the ramification of any single gap in the security architecture is difficult to measure and extremely complex to cost. However, if accomplished, the business case becomes a persuasive argument and one that is more likely to obtain funding, especially in these bleak economic times. Even in the most complex situations, I use this tool to contrast the costs of alternative solutions and, therefore, highlight the rationale behind the adoption of certain solutions. Business cases come in a variety of different forms and many are corporate standards to ensure comparability between different ventures but, regardless of the format you use, the business case needs to clearly illustrate the: Costs involved Manner in which each solution will integrate into the business strategy and security architecture Operational control and ongoing governance model Level of regulatory or policy compliance Risks associated with the solution, and those that arise by not adopting the solution PowerPoint to the Rescue The business case is a key tool, but too often it is simply not read and appreciated by senior management, who often lack the time and technical understanding to interpret these documents. Therefore, I would advocate the use of PowerPoint (or equivalent) as an invaluable tool, simply because over the years countless external consultants have conditioned management to think in terms of slides (or single frames). Therefore, use this to your advantage, and supplement all your business plans with a two- to five-page PowerPoint presentation. If you cannot display your business case in about five slides, it is unlikely you will successfully obtain the funding you seek. An example presentation could contain the following: Slide 1: Current state vs. future state Slide 2: Description of exactly what you want approved Slide 3: Benefits flowing to the business Slide 4: Risk distribution (for current and future state) Slide 5: A financial analysis (including implementation and maintenance costs) This approach delivers a short, very direct request to management that can be squeezed into any meeting without consuming large amounts of their time. For these reasons, it is more likely to be heard, understood and considered seriously. Policy Advocate This is the final issue to be addressed. Every organisation has (or should have) a wealth of policies and procedures, all of which have originated for a purpose and most actively work to maintain and enhance corporate governance. However, I am sure that every practitioner has seen at least one policy that, due to the wording or the context in which it was created, is now extremely difficult to implement. In these situations, the SecArch needs to play the role of the advocate and work with the policy-makers to shape the security requirements into something that are practical, thereby avoiding requirements that would demand exceptions and undermine the integrity of the policy.

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 1, 2003

When SecArchs adopt this stance they will encounter some resistance and may be unpopular with other security professionals. However, through tools, such as a risk assessment and business case, it should be easy to objectively illustrate why some draft policies need to be modified before they are adopted. On the other hand, where policies are adopted, they need to be communicated and quickly incorporated into the security architecture. Good architectural documentation, an up-to-date risk assessment and experience with business case preparation will help architects develop their IS security environments in a direction that allows the continuing development of the security framework within the company.

5 6

7 8

Conclusion
This article has expressed the authors opinion regarding some of the challenges that he has encountered as a SecArch. These challenges are not unique and would be familiar to many practitioners. Techniques to address these problems are common business tools and techniques. However, the author has sought to highlight that a SecArch needs to be: Business aware, and capable of speaking a language that management understands (e.g., risk assessment and business case) An advocate of pragmatic security initiatives, with sufficient confidence and support to successfully argue for strong, pragmatic solutions In providing this service to the business, the SecArch needs to work actively with the other IS security professionals. The exact nature of this relationship will be explored at a later date, including the need to avoid overlapping responsibilities. While this can be achieved, I believe that SecArchs will continue to provide a valuable part of most major corporations and, through adopting some of the points discussed previously, provide an even higher level of service to their ultimate customerthe end user.
9

10

11

12 13

Boar, Bernard H., Constructing a Blueprint for Enterprise IT Architectures, John Wiley & Sons, 1999, p.34 Ibid., p.30 It is possible that involvement in project management could cause your architecture team to number more than 10 percent of your total IT department. This is a significant investment and may possibly limit your involvement in some projects. Ibid., Boar, p.35 Constructing a Blueprint for Enterprise IT Architectures provides a detailed description of one approach to documenting enterprise architectures. Coupled with UML, this approach could provide a good result, although I personally have not had the opportunities to use these techniques. Other practitioners also discuss the use of business impact analysis, which also can provide insight to robustness of the security architecture. Ibid., Boar, p.28, 76 Examples of the risks to be considered include: business interruption; inability to provide operational support; loss of data integrity on servers; loss of data integrity on notebook(s); loss of data integrity on mainframe; breach in perimeter network security; breach of internal network security; virus, legal or regulatory breach. Developing risks at this level helps presentation of the results to management and ensures that the risk assessment does not become too cumbersome. Much has been written on risk assessments, but the following references include assessing the cost of avoiding the risk within the risk assessment process. This is a valuable concept and one worth adopting. King, Dalton and Osmanoglu, Security Architectures, McGraw-Hill, 2001, p.44, 48 Ibid., Boar, p. 36 Ibid., p.60

Footnotes
1 2 3

Kern, Galup and Nemiro, IT Organisation: Building a world class infrastructure, Prentice Hall, 2000, p.4-5 This is due mainly to legal requirements. While not being a universal position, one survey recently suggested that the IT architect function exists within 70 percent of modern companies. Kern, Galup and Nemiro, IT Organisation: Building a world class infrastructure, Prentice Hall, 2000, p.37

Tim Scammell, CA, CISA worked in Australia, Germany, England and Switzerland for nine years within one of the major accountancy firms performing a variety of tasks ranging from regulatory compliance to consulting. This work addressed computer security and operational issues in a diverse client base.

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the Information Systems Audit and Control Association, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal. Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content. Copyright 2003 by Information Systems Audit and Control Association Inc., formerly the EDP Auditors Association. All rights reserved. ISCATM Information Systems Control AssociationTM Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25 per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited. www.isaca.org

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 1, 2003