Security Frameworks Robert M. Slade, MSc, CISSP rmslade@shaw.ca, rslade@vcn.bc.ca, rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm The phrase "security framework" has been used in a variety of ways in the security literature over the years, but in 2006 it came to be used as an aggregate term for the various documents (and some pieces of software), from a variety of sources, that give advice on topics related to information systems security, in particular regard to the planning, managing, or auditing of overall information security practices for a given institution.

Security frameworks Guidelines Principles Standards Frameworks/breakdowns/structures Checklists Software “Best Practice” Audit guidelines/outlines Legislation Reporting standards Product evaluation Some of these texts are guidelines specifically addressed towards information security, such as British Standard 7799 and its descendants, particularly the ISO 27000 family of standards. In this category are also items such as the (free, both of charge and of access) "Self-Assessment Questionnaire" prepared by the United States National Institute of Standards and Technology (NIST) (identified among their publications as 800-26). There have been a number of projects that attempted to produce similar sets of standards or practice lists, such as the now moribund CASPR (Commonly Accepted Security Practices and Recommendations), two versions of GASSP (Generally Accepted System Security Principles): these listed undertakings have been amalgamated into GAISP (Generally Accepted Information Security Principles). Other frameworks are peripherally related, but have come to be seen as having a bearing on system security. Probably the most widely known are the auditing standards and outlines such as COBIT, and the variety of supporting documents and processes that have grown up around the United States' Federal Information Systems Management Act (FISMA). Others are more distantly associated, such as the Common Criteria on specifications and evaluation.

Security frameworks Financial reporting instructions Sarbanes-Oxley/Sarbox/SOX, COSO, Turnbull, Basel II Reliability of reported finances Information systems source of reports Internal controls Information system controls Insider attack, fraud? Still others are even more tenuously connected, such as the advice on fraudulent financial reporting from COSO. (The various financial instructions are generally concerned with the accuracy and reliability of reported earnings and the financial health of a company: this is felt to have implications for the management and controls on information systems, which are the primary source of all corporate data, including that related to finance.)

Security framework types Governance Breakdowns/frameworks Checklists Controls lists Risk management Infosec, business, and banking Process oriented Audit and assurance There is frequent confusion in regard to the term governance and what differentiates it from management. Some note that management might be said to increase direct performance, while governance may, through analysis, redirect activities to greater effect. (In a sense this only moves the question back one level: this simply seems to be the distinction between strategic and operational management.) Some texts also note that five basic classes of decisions must be made in IT: over principles, architecture, infrastructure, business application needs, and the priorizing of investment, and that these constitute the areas of governance. A number of the governance related security frameworks are primarily sets of divisions of activities and functions. These types of security frameworks are, in fact, the most likely to use the word "framework" in the title or description of the process. The entities provide structures that provide for the breaking down of the overall organization and operations of an institution into smaller areas that may aid in the analysis of specific risks, security requirements, and weaknesses. A significant number of security frameworks are presented in checklist form. This preference for the checklist format is hardly surprising: security is not a single function, but a compilation of a number of functions. Indeed, it is frequently pointed out that tremendous expenditures on security may be entirely obviated by the lack of a single control, and therefore a checklist of functions to be covered makes a great deal of sense. The finer grading and codifying of controls that we can do, the better our analysis of our total security posture, and the two classifications are orthogonal. Therefore the two divisions can be used as the basis for a matrix of controls, which can be used to assess the completeness of protection for a given system. Details of the process may be found in volume 3 of the 5th edition of the "Information Security Management Handbook, pages 179-182.

Weaknesses Content limitations Define “Secure” “Best Practice” One weakness that is very common across all the security frameworks is the narrow focus to a particular area, topic, or approach. Security should be a holistic practice, with input from a variety of fields and a wide-ranging overview of the problem, as well as details suitable to the situation or environment. As Eugene Spafford has famously said, a secure system is one that does what it is supposed to. Therefore, it is impossible to define a state of security that is applicable to all computers, since not all computers are, in the minds of the users, supposed to do the same thing. Does the best practice mean something that will work for everyone in all situations? We have already determined that there is very little (possibly nothing) that will be "secure" in any and every environment. Does best practice mean a minimum level of security required by all? Does it mean an optimal balance? We don't know. There is no agreed upon definition of "best practice."

BS 7799/ISO 27000 family BS 7799 Part 1 BS 7799 Part 2 ISO 27000 ISO 17799, ISO 27002 code of practice 133 controls, 500+ detailed controls BS 7799 Part 2 ISO 27001 Information Security Management System (ISMS) ISO 27000 ISMS fundamentals and vocabulary, umbrella 27003 ISMS implementation guide, 27004 ISM metrics, 27005 infosec risk management, 27006 certification agencies, 27007 audit British Standard 7799, Part 1, is one of the earliest frameworks specifically addressing information security, and is currently probably the most important and widely used. Subsequent to its adoption as BS 7799-1 it became of significant interest to the information security community world-wide. The International Organization for Standards used BS 7799-1 as a model for developing multiple versions of ISO 17799: the current standard is ISO 17799:2005. In order to promote consistency of numbering in the 27000 family of security standards, ISO 17799 is being redeveloped as ISO 27002. BS 7799 seems to have promoted the use of the phrase "Information Security Management System" and the use of the acronym "ISMS" is an indicator of a BS 7799 influence. BS 7799 Part 2 deals with ISMS requirements, and is used within companies to create security requirements and objectives. As noted, the ISO standards related to security are being renumbered (as they are updated) and new standards are being added in the 27000 range. ISO 27000 itself will be about ISMS fundamentals and vocabulary, and will essentially be the introduction to (and umbrella for) the whole group of standards. ISO 27003 will be ISMS implementation guidance, 27004 talks about infosec management measurements and metrics, 27005 is infosec risk management, 27006 is for accreditation of certification agencies, and 27007 will deal with audit guidelines.

COBIT ISACA (formerly Information Systems Audit and Control Association) Four phases/domains: Planning and Organization Acquisition and Implementation Delivery and Support Monitoring Widely used and, until the rise of BS 7799-1, probably the most recognized of the security frameworks, COBIT (Control OBjectives for Information and related Technology) is directed at information security. However, it should be noted that COBIT was created by a specific group and intended for a specific purpose. COBIT was created by ISACA (which used to be known as the Information Systems Audit and Control Association). Auditability is key to the COBIT, and the accounting and management background definitely shows in the choice of items in the COBIT list. Much of the activity suggested relates to measurement, performance, and reporting. Thus, in a sense, most of COBIT concentrates on what can be counted and demonstrated, sometimes disregarding what might actually be effective.

Common Criteria (CC) Common Criteria for Information Technology Security Evaluation ISO 15408 not a security framework not even evaluation standard Framework for specification of evaluation Protection Profile (PP) Evaluation Assurance Level (EAL 1-7) Contrary to much mistaken opinion, the Common Criteria (more properly the Common Criteria for Information Technology Security Evaluation, and also ISO 15408) is not a security framework or standard of practice. It isn't even a standard for evaluating security products or systems. The Common Criteria (or CC) is a structure for specifying product and product evaluation standards. Sources of information about the CC have tended to bounce around. For a while you could go to commoncriteria.org, then that disappeared and the best place to get an idea of how it worked was at the NIST Website. At the moment the site http://www.commoncriteriaportal.org/public/expert/index.php?menu=2 seems to be working. There are generally three parts, or documents, related to the CC overall. Part One is a general introduction, outlining the basic ideas and major terminology used. The Part One document isn't hard to read, and probably every security professional should have read through it at least once.

FISMA Federal Information Systems Management Act – US National Information Assurance Certification and Accreditation Process (NIACAP) National Institute of Standards and Technology outline, Defense Information Technology Systems Certification and Accreditation Process (DITSCAP) Director of Central Intelligence Directive 6/3 The United States' Federal Information Systems Management Act mandates certain standards of information security and controls for US federal agencies. The legislation states that standards must be applied, but the standards are different for different agencies and applications. Detailed instructions can be found in directives for the military (Defense Information Technology Systems Certification and Accreditation Process or DITSCAP), the intelligence community (Director of Central Intelligence Directive 6/3 or DCID 6/3), and more generally the National Information Assurance Certification and Accreditation Process (NIACAP). The National Institute of Standards and Technology also has outlines.

Information Security Forum (ISF) Standard of Good Practice for Information Security 5 "aspects" Security Management Critical Business Applications Computer Installations Networks Systems Development broken out into 30 "areas," and 135 "sections" www.securityforum.org http://www.isfsecuritystandard.com/pdf/standard.pdf The Information Security Forum (ISF) Standard of Good Practice for Information Security is a guideline forming a checklist of policies (or even attitudes) that the company or employees should have. It is structured in five "aspects" of Security Management, Critical Business Applications, Computer Installations, Networks, Systems and Development. These aspects are broken out into 30 "areas," and the areas into 135 "sections." The ISF standard is, however, one of the few frameworks available without charge. The 247 page document (currently the 2005 version) does provide useful advice in a number of areas (although the early material is primarily promotional in nature). It can be downloaded from the ISF Website at www.securityforum.org or http://www.isfsecuritystandard.com/pdf/standard.pdf

ITIL Information Technology Infrastructure Library management guidelines Incident response Problem management Change management Release management Configuration management Service desk management Service level management Availability Capacity management Service continuity IT financials IT workforce/HR management security removed in recent revision influenced BS 15000, ISO 20000 The Information Technology Infrastructure Library is a massive (and expensive) set of documentation aimed at improving information technology service management. Proper management generally leads to better security, so it fairly naturally follows that this library of practices would be of interest to information security. Security itself was originally part of ITIL, then was removed to be addressed separately, and has now been returned.

Management frameworks Zachman Framework Calder-Moir Framework Balanced Scorecard The Zachman Framework is a two-dimensional model used to analyze an organization or process by breaking it down into smaller characteristics or considerations. Instead of trying to look at the entire enterprise at once, you break it down into a grid of perspectives and viewpoints. Supposedly in order to help you get the various security frameworks to work together harmoniously, the Calder-Moir IT Governance Framework is really only a graphical classification of the various frameworks in terms of whether they address the topics of business strategy, business and risk environment, IT strategy, operations, capabilities, and change management. The "balanced" part of Balanced Scorecard is a reminder to view business processes from multiple perspectives, and not to neglect any. Specifically, the process recommends setting objectives, and measuring performance, for the learning and growth (employee training), (internal) business processes, customer (satisfaction), and financial perspectives. It is very concerned with metrics and measurement-based management.

NIST library of freely available resources http://csrc.nist.gov Information Security Handbook: A Guide for Managers 800-100 Recommended Security Controls for Federal Info Systems 800-53 Guide to Information Technology Security Services 800-35 Risk Management Guide for Information Technology Systems 800-30 Engineering Principles for Information Technology Security 800-27 Guide for Developing Security Plans for Federal Info Systems 800-18 Generally Accepted Principles and Practices for Securing Information Technology Systems 800-14 An Introduction to Computer Security: The NIST Handbook 800-12 Security Self-Assessment Guide for Information Technology Systems 800-26 It really isn't fair to compare the Computer Security Resource Center (CSRC) of the United States' National Institute of Standards and Technology, with the security frameworks we have been discussing. The centre (which, even though it is only one office of the institute, is generally known simply as NIST in the security community) provides a wealth of security information and resources, which are freely available at the Website at http://csrc.nist.gov. The publications section is particularly useful, with a constantly updated stream of guidelines and aids, particularly the 800 series documents.

OCTAVE Carnegie Mellon University risk management Operationally Critical Threat, Asset, and Vulnerability Evaluation Carnegie Mellon University risk management The OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) process is a risk management method from Carnegie Mellon University. It is a formal and detailed set of processes, and will assist in ensuring that risks are identified and properly analyzed, following the standard techniques used in most risk analysis procedures. However, due to the level of activity and overhead involved in OCTAVE, it is probably best suited to large organizations or projects.

Securities and Financial Basel II bank solvency “operational risk” COSO Committee of Sponsoring Organizations of the Treadway Commission, Enterprise Risk Management Integrated Framework internal controls SOX As should be clear to everyone in both fields, the financial securities industry has very little to do with computer or information security, despite a heavy reliance on the technology. However, recent concerns in that community have concentrated on the area of internal controls, which have application in reviewing controls and safeguards, particularly in regard to insider attacks. This reference is shorthand for the second report from the Basel Committee on Banking Supervision, Risk Management Principles for Electronic Banking. Basel II Accord also looks at operational risk, which is more in line with the risk management that infosec people know and love. Shorthand for the Committee of Sponsoring Organizations of the Treadway Commission, Enterprise Risk Management Integrated Framework. Shorthand for the Committee of Sponsoring Organizations of the Treadway Commission, Enterprise Risk Management Integrated Framework. COSO outlines a three dimensional framework for examining controls. The United States' Sarbanes-Oxley law (frequently referred to as Sarbox or SOX) emphasizes that corporate management is responsible for the reliability of financial reports about publicly traded companies. Section 404 (and also 302, in a marvelous confusion with Web result codes) notes that the integrity of information systems supporting these financial reports must also be managed.

Security Governance part of “CISO Toolkit” (Fred Cohen) structured according to business concepts, rather than security topics easier for businesspeople to understand checklist in book form 900 checks Many of the security frameworks available are in the form of a checklist, so why shouldn't the "Security Governance" list-in-book- form for Fred Cohen's CISO Toolkit be included? In fact, Cohen's version may be considerably easier to understand and use, particularly for those with a business, rather than a security, background. While most security frameworks are structured according to a taxonomy of security concepts, the checklist in "Security Governance" is based on business models and concepts. The businessperson working through the points will start with the familiar, and only later have to face items directly discussing security. (Even then, the security issues are those regarding the position and management of security within the organization.)

SSE-CMM Systems Security Engineering Capability Maturity Model Basic (chaotic/informal) Planned and verified Well defined and coordinated Measurable and quantitatively controlled Constantly improving (optimizing) The Systems Engineering Capability Maturity Model, more generally known as the Capability Maturity Model or CMM, is an attempt to apply standards of engineering rigour to information systems technology development. Researchers at Carnegie Mellon University noted that many technology products and applications succeed based primarily upon being the first to address a need, even if it is addressed very poorly. (Many more programmes and systems fail along the way.) The model identified different levels of maturity of organizations, in terms of processes, documentation, and discipline in an approach to development and change. The original model identified levels starting at informal or chaotic, through repeatable, documented, managed, and finally ending at continually improving. These structures and observations have been modified and applied to more specialized fields. The Systems Security Engineering Capability Maturity Model (SSE-CMM) addresses the planning, development, and management of security, and security architecture for an enterprise.

Which one? no framework best for all no one-size-fits-all in security no framework sole source for any enterprise multiple frameworks, multiple perspectives Which one addresses a viewpoint you haven't used? While this article can only be the merest introduction to the security frameworks themselves, it should provide a general idea of the types of frameworks that are available, and the relative areas of relevance and application for specific frameworks. Hopefully the reader will also have noted that just as no one security framework is suitable for all situations and applications, so no single framework should be relied upon as the sole guide for any enterprise. Multiple perspectives are necessary to provide for realistic security, and multiple documents have additional viewpoints to add to the construction of a security architecture. Each folio should be considered to see if it has something to add to your security program.

Security Frameworks Robert M. Slade, MSc, CISSP rmslade@shaw.ca, rslade@vcn.bc.ca, rslade@computercrime.org http://victoria.tc.ca/techrev/rms.htm This presentation, and the notes supporting it, are the work of Robert M. Slade, who holds the copyright to it. Permission is granted for anyone to use this material in any event for which no charge is made, as long as the material is not modified, and is made freely available to those who request it. Copyright Robert M. Slade, 2007