Technical Report RHUL–MA–2015–3 4 March 2015

The Value of Threat Models in Enterprise Security Testing of Database Systems & Services Timothy D. Williams

Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom

www.ma.rhul.ac.uk/tech Student Number: 100758891 Name: Timothy D. Williams

The Value of Threat Models in Enterprise Security Testing of Database Systems & Services

Supervisor: Dr. Lorenzo Cavallaro

Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London

I declare that this assignment is all my own work and that I have acknowledged all quotations from the published or unpublished works of other people. I declare that I have also read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Oﬀences and in accordance with it I submit this project report as my own work.

Signature:

Date:

Academic Year 2013/2014 Copyright c 2013/2014 by Timothy D. Williams

Abstract

The Value of Threat Models in Enterprise Security Testing of Database Systems & Services

by Timothy D. Williams

Master of Science in Information Security

Royal Holloway, University of London 2013/2014

This thesis explores the value of threat models in organisation-wide security testing of databases. Factors that drive security testing are explored. Different types of security testing, different approaches to threat modeling and different database technologies are considered. The importance of metadata management, particularly for newer schema- less databases, is highlighted. An integrated approach to database security testing is proposed which includes white-box, black-box and grey-box techniques. Sequence dependencies affecting database security testing are identified. The need for explicit architecture tiers in database security testing is explained. An approach to threat modeling and testing based on zones is proposed. Potential benefits of the proposed approach are described. The main conclusion is that further research is needed, both theoretical and applied, into the best ways for organisations to plan, execute and respond to database security tests. It is possible that a similar threat-based approach could be applied to testing other architecture components. A number of other possible research topics are identified including: threat information exchanges, threat model tool development and penetration test data management.

Keywords: database security, threat modeling, security testing, functional testing, penetration testing, enterprise security, governance, compliance, cybersecurity.

iii iv Acknowledgements

I am very grateful to my family and in particular to my lovely wife Fiona for supporting me as I have had to prioritise MSc study time and work commitments over time that I would normally have enjoyed with them. I would like to thank my mother Diana for checking late drafts for errors. I am fully responsible for any remaining errors. This project would not have taken shape without the guidance and support of my supervisor Dr. Lorenzo Cavallaro to whom I will feel for ever indebted. My background understanding of systems thinking and software quality assurance owes a great deal to the wonderful Dr. Gerald M Weinberg to whom Phil Stubbington virtually introduced me in an online forum in 1999. I am enormously grateful to Jerry (as he likes to be known) for his writings, for his online mentoring over the years and for the privilege in November 2012 of finally meeting him in person. The way in which I think about information risk management problems and security architecture solutions owes much to what I have learned about “defence in depth” since 2005 through working on secure public sector projects. Although these sources may have indirectly influenced my thinking, only the sources listed in the Bibliography have been relied upon and no classified information is disclosed in this thesis. For making me think hard about metadata management issues and improving my understanding of metadata solutions I am very grateful to my former colleague George McGeachie. For raising my understanding of PostgreSQL security I would like to thank Simon Riggs. For introducing me to attack monitoring in 2010 I would like to thank Joerg Weber. For being a dedicated independent security researcher [11] and supportive work colleague I would like to thank Jerome Athias. A special mention is due to Wayne Grundy for his recommendation in 2010 that I read “The Pyramid Principle: logic in writing and thinking” by Barbara Minto [239]. Whenever I was getting stuck it was a great help to re-read and reflect on the helpful advice that this book provides. I would also like to thank members of the Information Security Group at Royal Holloway, and in particular Dr. Chez Ciechanowicz and Emma Mosley, for their support and understanding during the difficult period following my father’s death at the start of January 2014.

v I dedicate this work to the memory of my father Anthony David Williams.

I consider myself blessed that along with strong faith, wise words and happy memories Dad passed on his optimistic outlook, enquiring mind and interests in practical details.

vi Contents

1 Introduction1 1.1 Audience...... 2 1.2 Motivation...... 3 1.3 Goals...... 6 1.4 Scope...... 6 1.5 Approach...... 7 1.6 Structure...... 8 1.7 Summary Findings...... 12

I Enterprise Context 15

2 Enterprise Information Governance 17 2.1 Corporate Governance...... 18 2.2 General Legal Obligations...... 19 2.3 Speciﬁc Legal Requirements...... 21 2.4 Summary...... 22

3 Good Practices 23 3.1 Enterprise Risk Management...... 23 3.2 Business Analysis...... 24 3.3 Data Management...... 25 3.4 Architecture Frameworks...... 25 3.5 IT Service Management...... 26 3.6 Cyber Security Frameworks...... 27 3.7 Lifecycle Models...... 28 3.8 Summary...... 31

4 Metadata Management 33 4.1 Prerequisites for Database Security...... 33 4.2 Value of Metadata...... 34

vii 4.3 Metadata History...... 35 4.4 Metadata Classiﬁcation...... 35 4.5 Metadata Security...... 38 4.6 Summary...... 38

5 Security Testing 41 5.1 Security Testing Overview...... 42 5.2 Software Quality Assurance...... 42 5.3 Security Test Planning...... 44 5.4 Timing of Security Testing...... 44 5.5 Security Testing Techniques...... 45 5.6 Security Testing Methodologies...... 47 5.7 Security Testing Challenges & Opportunities...... 48 5.8 Summary...... 51

6 Threat Modeling 53 6.1 What is Theat Modeling?...... 53 6.2 Why is Threat Modeling Valuable?...... 54 6.3 When are Threat Models needed?...... 55 6.4 Threat Modeling Approaches...... 55 6.5 Summary...... 61

II Database Security Testing 63

7 Database Security Management Review 65 7.1 Overview of Database Security Management...... 65 7.2 Core Database Services...... 67 7.3 Database Service Management...... 69 7.4 Limits of Database Security Management...... 71 7.5 Summary...... 72

8 Database Security Technical Review 73 8.1 Traditional Technical Database Security...... 74 8.2 Database Technology Trends...... 74 8.3 New Database Security Limitations...... 75 8.4 Worked Examples of Database Security Attacks...... 76 8.5 Database Security Test Alignment...... 78 8.6 Summary...... 79

9 Database Security Testing Framework 81 9.1 The Need for Database Security Threat Models...... 81 9.2 Framework Development Decisions...... 82 9.3 Framework Description...... 85 9.4 Framework Rationale...... 86 9.5 Principles...... 90 9.6 Summary...... 92

viii III Potential Improvements 93

10 Evaluation 95

11 Conclusions 97

12 Future Directions 99

IV Appendices 103

A. Typographic Information 105

B. Bibliographic Information 107

C. Glossary of Terms 109

D. Enterprise Risk Management 115

E. Software Testing Standards 117

F. NIST Cyber Security Framework 119

Bibliography 120

ix x List of Figures

1.1 Database Security Testing Concept...... 1 1.2 Information Security Management process...... 3

2.1 Corporate Governance Summary...... 18

3.1 ISO/IEC 9126 Software Quality Attributes...... 25 3.2 ITIL Service Catalogue...... 27

4.1 Data Value Chain...... 34

6.1 Threats, Requirements, Mitigations Interplay...... 58 6.2 Vulnerabilities of Countermeasures...... 59

7.1 DAMA Data Security Management processes...... 70

8.1 NoSQL Data Models...... 75

xi xii List of Tables

1.1 Five Research Goals...... 6 1.2 Questions related to ﬁrst goal...... 9 1.3 Questions related to second goal...... 9 1.4 Questions related to third goal...... 10 1.5 Questions related to fourth goal...... 10 1.6 Questions related to ﬁfth goal...... 11

3.1 Initial V-Model Based Concept for Database Security Testing Framework 30

6.1 Main Focus of Threat Modeling Approaches...... 56

9.1 Threat-Based Database Security Testing Framework...... 86

12.1 Glossary of Key Terms...... 109

12.2 NIST Cybersecurity Framework Core...... 119

xiii xiv ”The job of system design calls for an eye that never loses sight of the forest, whereas the job of debugging requires that every tree - even every branch or leaf - be seen with utmost clarity. ” Gerald M. Weinberg (b. 1933) 1 Introduction

This thesis explores ways in which it may be possible to improve the security of databases if threat models are used to guide the design, execution and continuous improvement of security testing processes.

Figure 1.1: Database Security Testing Concept

As evidenced by the recent data breach at eBay [94] and others [124, 63], important databases both large and small are now demonstrably vulnerable.

The root causes of major data breaches may not be disclosed. Organisations and individuals need to protect their reputation. If legal investigations are ongoing, due process will prevent release of evidence.

1 However it is possible that such breaches are occurring due to:

inadequate management understanding of the security threats posed by new database • technologies such as those that were being used by eBay [335, 253]; and/or

insuﬃcient or ineﬀective security testing of database systems [92]. •

All organisations are dependent on software to support internal information processing and information exchanges with other organisations.

Databases are software engines upon which many other applications depend. Since databases are so important, since threats are increasing and since testing contributes to information assurance, it is important to consider these topics in combination.

Given the known importance of database technologies and the known high levels of risk involved in allowing access to databases via the Internet, at the outset I expected to ﬁnd an extensive body of recent literature on enterprise security testing of database systems.

What I have found is that recent literature on security testing of database systems is actually rather limited.

Most database security research seems focused on particular technologies [215, 214], security properties and vulnerabilities ([129, 111]) rather than on the challenges of ensuring the security of multiple database technologies at an organisational level.

Chapter Structure

Having brieﬂy explained the high level rationale and the surprising discovery that there is not already a large body of similar literature, the remainder of this chapter more fully explains the intended audience 1.1, my motivation 1.2, the research goals 1.3, the project scope 1.4, the approach 1.5, the structure 1.6 and the summary ﬁndings 1.7.

1.1 Audience

This thesis is written primarily from the perspective of internal stakeholders. Some form of Information Security Management System (ISMS) is likely to be in place.

2 Figure 1.2: Information Security Management process per [279, p 90 ﬁg 4.11]

The security function may be well resourced or not. The ISMS may not have been independently audited. Security testing may or may not be occurring already. What is important is that target audience has a personal stake in the organisation’s success. Compliance matters. Security matters. Eﬀectiveness and eﬃciency matter.

1.2 Motivation

Why Focus on Security Testing? In recent years as a professional security consultant I have been involved in planning, executing and interpreting the results of security tests, some focused on infrastructure, some focused on applications and some covering both. When I heard at the start of studying for this MSc in the Autumn of 2012 that it was possible to follow a track specialising in testing, although I was not sure initially what aspect of security testing I wanted to focus on, I made the decision to follow this track. This decision aﬀected subsequent option selections and committed me to writing a thesis related to security testing. Although the activity of testing does not in itself improve security, I strongly believe that appropriate security testing should be performed whenever any changes are made to any system because security testing can:

highlight errors, weaknesses and control gaps which need to be remediated; • give confidence that controls are adequate to deal with defined threats; and • indicate the degree of robustness of security protection mechanisms. • 3 Why Focus on Databases? This question can be answered in a general (impersonal) manner and in personal terms. Firstly, all information systems are dependent on data. Inputs are data. System configuration items are data. Processes operate on data. Outputs are data. For many years it has been accepted that a Data Base Management System (DBMS) of some kind is an important system component. Although not everyone would agree with C.J. Date’s assertion that “The DBMS is easily the most important software component in the overall system...” [75, p 7], few would disagree with Date that using a DBMS can deliver significant benefits including:

maintaining information and making it available on demand [75, p 4]; • supporting data integration and sharing [75, p 6]; • shielding users from hardware-level details [75, p 7]; and • centralised control of enterprise data [75, p 13]. • Secondly, I have a personal interest in database security as a result of using a wide range of diﬀerent database technologies over the course of over twenty-ﬁve years of varied work experience. When deciding what aspect of security testing to focus on in the Autumn of 2013, I realised that this was probably the topic in which I had the greatest amount of background knowledge. I was also aware that in recent years many new database technologies have come onto the market [341, 96, 27]. Although many of these technologies have not yet entered the environments in which I work, a key personal learning goal behind the decision to focus this thesis on database security was the desire to learn more about the security challenges and opportunities which new database technologies present.

Why Focus on Threat Modeling? At a high level security is about protecting self-interests, about being open to opportunities but closed to threats. Threat modeling may be used to improve understanding of how to facilitate legitimate access while limiting the probability and impact of adverse events. An interesting 1999 article by Schneier [321] describes the use of attack trees to provide a formal, methodical description of the security of systems. Formal deﬁnition of threats also forms part of the Common Criteria (CC) process for formal security evaluation of Information Technology (IT) products [174, p 62], [58, 231]. Threat modeling may also be performed as part of broader organisational security assurance processes. Organisations (including large end users, major technology vendors and specialist information security groups) have publicly supported the use of threat modeling. These include:

US Government Department of Homeland Security (DHS) [259]; • Intel [307]; • 4 Microsoft [229]; • MITRE [374]; and the • Open Web Application Security Project (OWASP) [280, 110]. • Why link Threat Modeling with Security Testing? Firstly it is already considered good practice by several reputable authorities. Although not all organisations rely on IT products the security of which has been formally evaluated (i.e. tested) under the CC scheme, the mandatory content for a CC Protection Profile (PP) includes a security problem definition detailing threats [174, p 62]. Links between threat models and testing are also recommended in literature of academic [375, 359, 312] and commercial [145, p 569-605], [334, p 29] heritage. Secondly security testing of systems is an expensive process not only in terms of the resources required but also in terms of the opportunity costs. All the time that systems are being tested, they are not available for use. Furthermore skilled security specialists who could be adding value earlier in the lifecycle of other projects are tied up performing tests. Thirdly security testing of systems is an error-prone process. A security test which finds a fault where there is none (i.e. a “False Positive” or Type I Error) causes time and effort to be wrongly expended. Such a test causes inefficiency. A security test which fails to find a fault which does exist (i.e. a “False Negative” or Type II Error) is more serious. Such a test is ineffective. If such an error were not to be detected then it could wrongly be believed that a system is more secure than it actually is. Fourthly having observed informally that experienced penetration testers make use of implicit threat models when deciding what tests to perform, I believe that the explicit use of Threat Modeling as a guide to security testing may reduce the incidence of Type II errors. Properly identified and classified threats can be regarded as leading indicators for risks. As this thesis will seek to demonstrate, the more commonly used approach of risk-based testing is at least one step removed from consideration of factors which can provide early visibility of where future risks are likely to occur.

5 1.3 Goals

The main research goals of this thesis are summarised in the following table:

Table 1.1: Five Research Goals

Number Goal Related Questions Related Chapter(s) 1 To explore reasons why threat-based Table 1.2 2,5&6 security testing may be valuable 2 To clarify what characteristics a Table 1.3 3&4 framework for security testing of databases needs to have in order to be valuable 3 To understand the diversity of database Table 1.4 7&8 security requirements and solutions 4 To deﬁne a threat-based framework for Table 1.5 9 database security testing which exhibits the desired characteristics 5 To consider how the proposed Table 1.6 10, 11& 12 framework could be improved

The chapter counts do not exactly reﬂect the diﬃculty of each goal. Goals 2 and 4 required greater deliberation due to the need to balance novelty with compatibility, whilst maintaining traceability to sources. Goal 3 involved consideration of many sources which were ultimately not relevant.

1.4 Scope

This thesis considers a diverse sample of ”traditional” databases (mostly relational) and “other”’ databases selected on the basis of literature introduced in Part II. The “other” databases include both established non-relational databases (such as directory services) and newer non-relational databases which are often described as NoSQL1 databases. The selected sample represents a very small proportion of the technologies currently in use. At the time of writing in August 2014 a website focusing on NoSQL technologies was tracking 150 such databases [96] while a website tracking database popularity included summary details for 222 database technologies [341]. However the chosen sample is intended to be suﬃciently diverse to gain a clear understanding of the extent to which security threats and testing requirements diﬀer depending on the technologies used. In addition to technical scope limitations, a number of other scope limitations were found to be necessary during the course of the project. More detailed scope limitations are explained in context. However it important to explain the major scope limitations in this introduction:

1The category “NoSQL” is loosely deﬁned but for consistency with several sources including [113, 224, 297, 96] and since some of these new databases are starting to provide SQL interfaces the deﬁnition “Not only SQL” will be used.

6 1. This thesis makes the case for threat-model driven security testing of databases, but does not itself deliver a reference threat model for database systems. 2. The framework for threat-based security testing of database systems and services proposed in this thesis is not intended to be used on its own. It is intended to be integrated with an organisation’s existing standard processes, which may already have been influenced by or aligned with other frameworks. 3. A related limitation is that this thesis does not itself fully explore the most effective ways to integrate the proposed threat-based approach to database security testing with any existing organisational processes. 4. It is also important to point out that this thesis does not fully explore database threats or database security requirements, nor does it fully explore differences between the architecture, design, security controls and vulnerabilities of different database systems and services. Applying the concepts of threat-based testing to different threat environments, security requirements, designs, security controls and vulnerabilities will deliver different test results. As far as possible this thesis endeavours not to bias test outcomes. The focus is on making a case for a threat- based approach to testing, which can be applied to a wide range of different business and technical scenarios. 5. No attempt is made in this thesis to map database related threats or vulnerabilities to controls. Some references are provided to other sources which may assist with control selection. The focus is on providing a lightweight process and structure within which: (a) initially identified threats can be mapped to appropriate controls; (b) threat models updated taking account of control vulnerabilities and changes in attacker behaviour; and (c) appropriate security tests designed which take account of potential threats to assets and associated controls. 6. Finally it is important to point out that although some technical details of the sampled database technologies are described, the focus is on identifying abstract principles which are likely to be generally applicable to security testing of databases. In any future practical implementations of this framework, executable database security test plans will need to be developed. Whenever executable test plans are being developed, it will be necessary to supplement the core reference materials provided by this framework with additional technical details specific to the business context. In order to plan and execute appropriate context-specific tests, it will be necessary to research the context-specific technical threats, controls external to the database system and controls internal to the database system.

1.5 Approach

Although this thesis concerns the practicalities of planning and executing appropriate security tests of database systems and services, the basis of the proposals made in this

7 thesis is primarily theoretical, based on my analysis of available literature supported by previous practical experience. Some limited practical experimentation was performed to validate certain concepts. The results but not the methods are described where relevant. Since the basis of this thesis is primarily theoretical and since testing is a practical activity, potential ways in which this thesis could be validated and extended are identiﬁed in the ﬁnal three chapters.

1.6 Structure

This section explains how the ﬁve high level research goals described above at 1.3 were broken down and where these questions are addressed.

Thesis Structure Part I of this thesis contains a wide-ranging review of literature related to the enterprise context within which security testing of databases typically needs to be performed. Part I addresses the ﬁrst two of the ﬁve research goals set out in table 1.1.

Part II explores security aspects of database systems and services, starting with a high level review of database security management issues followed by a more detailed current state review of the key security threats applicable to a sample of different database technologies. Based on these examples, a skeleton framework is proposed under which the breadth and depth of database security testing may be guided by appropriate threat models. The framework proposes a generic approach to designing database security tests which allows for logically equivalent controls to be identified and tested appropriately according to their threat exposures. Recommendations are made for managing the residual risks of database security controls for which testing is unlikely to be effective or efficient. Part II addresses the third and fourth of the research goals set out in table 1.1.

Part III explores potential improvements to the proposed database security testing framework. Benefits and limitations of the proposed framework are explored. A number of potential extensions to the framework are considered. Part III addresses the fifth and final research goals set out in table 1.1. It also provides an overall summary and considers future possibilities.

Part IV contains Appendices, the most important of which is the Bibliography.

Research Questions From the ﬁrst goal “To explore reasons why threat-based security testing may be valuable” (see table 1.1) further questions were identiﬁed.

8 The following table lists these questions and identiﬁes where they are discussed:

Table 1.2: Questions related to ﬁrst goal

Question Explored in Part I at: Why is information risk management necessary? chapter2 Why do organisations need to perform “Enterprise Information information security testing? Governance” How does security testing demand diﬀer by sector? What is security testing? How does it relate to other types of testing? chapter5 When is security testing needed? “Security Testing” What can security testing measure? How can security testing be improved? What is threat modeling? Why is threat modeling valuable? When should threat modeling be done? chapter6 Are there diﬀerent approaches to threat modeling? “Threat Modeling” What are the most appropriate levels of granularity at which to perform threat modeling?

Exploring the second goal “To clarify what characteristics a framework for security testing of databases needs to have in order to be valuable” (see table 1.1) required the following questions to be considered:

Table 1.3: Questions related to second goal

Question Explored in Part I at: Which existing good practices would it be most chapter3 beneﬁcial for the security testing framework proposed in “Good Practices” this thesis to be aligned with and why? What life-cycle model, if any, should the security testing framework be aligned with? What are the prerequisites for eﬀective control of chapter4 database security? “Metadata What do all organisations need to know about their Management” data regardless of what databases they use?

The third goal “To understand the diversity of database security requirements and solutions” (see table 1.1) generated the following questions which are explored in Part II “Database Security”:

9 Table 1.4: Questions related to third goal

Question Explored in Part II at: What does database security management involve? What database services are required? What database services are available? How reliable are chapter7 they? “Database Security What needs to be done to assure delivery of the required Management Review” database services? What are the best practices for authorising and monitoring access to databases? What falls outside the scope of database security management? What technical security services do databases provide? What are the security strengths and limitations of chapter8 diﬀerent database technologies? “Database Security What threats are databases exposed to? Technical Review” How can diﬀerences in the security characteristics of databases be accommodated in a common testing framework?

The fourth goal “To deﬁne a threat-based framework for database security testing which exhibits the desired characteristics” (see table 1.1) led to the following questions:

Table 1.5: Questions related to fourth goal

Question Explored in Part II at: What content does an effective security testing framework for databases need to include? What types of testing does an effective security testing framework for databases need to include? How can a security testing framework for databases be chapter9 readily integrated with existing frameworks? “Database Security What architecture tiers does an effective security testing Testing Framework” framework for databases need to include? In what ways are existing good practice frameworks incomplete or divergent with respect to database security testing? Where are there gaps to be filled? Is there an optimal order to sequencing of different types of database security tests? What measurements can be used to assess the effectiveness of database security controls?

The ﬁnal goal “To consider how the proposed framework could be improved” (see table 1.1) resulted in the following questions being developed, exploration of which is deferred to Part III “Potential Improvements”:

10 Table 1.6: Questions related to ﬁfth goal

Question Explored in Part III at: In what ways can the effectiveness of the framework be assessed? Is it possible to demonstrate that the framework will chapter 10 improve alignment between the scale of threats and the “Evaluation of Database proven strength of security controls? Security Testing Framework”, Does the framework introduce any significant problems chapter 11 or complications? If so, can these be mitigated? “Conclusions” & What practical experiments could be performed to chapter 12 validate answers to these questions? “Future Directions” With the benefit of hindsight, what other questions could have been asked?

Chapter Structure This chapter1 and the last two chapters (chapter 11 “Conclusions” and chapter 12 “Future Directions”) have speciﬁc structures.

The start and end of the intervening chapters, which include the majority of the thesis ﬁndings, all share a similar structure as follows:

1. Each of these chapters starts with a brief, unnumbered “Chapter Overview” section which explains the chapter’s relationship to the ﬁve goals and describes the chapter structure. It also provides quick links to related chapters.

2. Each of these chapters ends with a “Summary” section which explains the chapter’s signiﬁcance, summarises how the chapter explored the related questions and outlines new questions and discoveries which will be explored in later chapters.

11 1.7 Summary Findings

Although database systems and services are undoubtedly becoming ever larger, more complex, more distributed and more technically diverse, the overall conclusions about the feasibility of implementing eﬀective database security tests for organisations exposed to multiple threats are positive. It is much simpler and more economical to assure the security of databases that are increasing in size and complexity if early account is taken of threats.

The key ﬁndings were:

Finding 1 - identifying clear, near universal, organisational needs for information • security testing (see 2.4);

Finding 2 - identifying gaps in coverage for security testing and database testing • in international software testing standards (see 5.2);

Finding 3 - an integrated approach to security testing of database systems is • needed including white-box, black-box and grey-box techniques (see 5.5);

Finding 4 - there appears to be no recent literature which comprehensively models • threats to database systems (see 6.4);

Finding 5 - currently available threat modeling tools do not support organisational • and technical views (see 6.4);

Finding 6 - the Data Management Body of Knowledge would beneﬁt from a • security focused update (see 7.3).

The key contributions of this work are as follows:

Oﬀering a partial solution to the challenges of how best to plan and execute • security tests of database systems and services (see 9.3).

Suggesting a possible way to integrate diﬀerent types of security testing2, thereby • bridging the gap between point-in-time, separately-scoped penetration tests which do not provide evidence of correct operation and the need to be able to provide positive evidence of correct operation for record-keeping and legal evidential requirements (standards for which are identiﬁed at 2.2);

Building on existing traceability between the US NIST cybersecurity framework • [265] and several other important frameworks (which is outlined at3);

Identifying testing sequence dependencies applicable to testing database systems • which limit the extent to which security testing of database systems can be performed in a fully agile/iterative manner (see 3.7);

Explaining the importance of metadata management and conﬁguration manage- • ment to database security testing (see4);

12 Explaining the beneﬁts of using the security zone2 construct to identify groups of • information assets which share common security controls and to use the deﬁned zones for threat modeling and test scoping (see 3.4,1);

Identifying the need for comprehensive database security threat models covering • organisational, zone, database and product architectural levels (see 9.1); and

Describing potentially worthwhile topics for further research, both closely related • to this thesis 12 and less closely related to this thesis 12.

The main argument supported by the work done is that threat modeling should be performed at several architectural levels and should contribute to the planning, execution and continuous improvement of database security testing processes.

Threat modeling and security testing, if implemented following structures, metrics and principles describedin chapter9, should not be barriers to organisations taking timely advantage of opportunities.

Implementing this security testing framework may allow organisations to:

clarify the nature and severity of the threats to their database systems and services; • assess the depth of their database security controls; • identify database security controls that are not suﬃciently independent of other • controls, which are therefore at risk of failing simultaneously and which need to be improved, tested and made ready for release.

2This thesis uses the term security “zone” in a generic sense to describe important internal security boundaries which can be used to deﬁne the scope of threat models and associated security testing. Potential users of the proposed framework should align use of the generic zone concept to their organisational reality. It was hard to identify a neutral generic term which did not have any existing associations. It is expected that the generic zone concept will be able to be mapped to the most similar organisation-speciﬁc security architecture term such as compartment, container, domain, division, enclave, environment, focus of interest, node, partition or segment.

13 14 Part I

Enterprise Context

“Some reckon that, currently, every two days, we create as much information as was created from the dawn of civilisation to 2003. Every two days! And it‘s growing at 40% per year....That’s why I‘ve called data the new oil. Because it‘s a fuel for innovation, powering and energizing our economy.” Neelie Kroes (b.1941) [207] cited by [17] 2 Enterprise Information Governance

Chapter Overview

Relationship to Goals As signposted earlier in chapter1 table 1.1 and table 1.2, this chapter explores some of the questions arising from the first of the five goals which is “To explore reasons why threat-based security testing of database systems may be needed”, given the target audience identified above at 1.1. This chapter focuses specifically on answering the following questions:

Why is information risk management necessary? • Why do organisations need to perform information security testing? • How does security testing demand diﬀer by sector? • The remaining questions arising from the ﬁrst goal are considered in chapters5 “Security Testing” and6 “Threat Modeling”, after the next two chapters3,4 which explore questions related to “Good Practices” and “Metadata Management” which arise from goal two.

Precis of Chapter Contents This chapter establishes that information risk management is a necessary element of corporate governance 2.1 and legal compliance 2.2. Some types of organisations and some industry sectors require information security testing 2.3. Most organisations are not explicitly required by external laws, regulations or commercial agreements to perform information security testing, but may nevertheless perform security testing to support organisational objectives 2.4. Note that most of the sources reviewed in this chapter do not refer to threat modeling, security testing or database security but are nevertheless relevant because they aﬀect the enterprise context for topics which are explored in this thesis.

17 2.1 Corporate Governance

Governance provides a framework of accountability to an organisation’s stakeholders [106, p 4]. Tricker provides an excellent background to this subject [352].

Figure 2.1: Corporate Governance Summary per [158, p 24 ﬁg 9]

Two corporate governance frameworks merit particular attention:

1. COSO The Committee of Sponsoring Organizations (COSO) of the Treadway Commission first published its “Internal Control - Integrated Framework” in 1992 [263] and updated it in 2013 [264]. This framework, which is commonly known as simply COSO, considers all entities (organisations) to have objectives which fall into three groups: Operations, Reporting and Compliance [264]. In order to meet these objectives COSO [264] identifies requirements for the following five internal control components to be integrated:

Control Environment; • Risk Assessment; • Control Activities; • Information and Communication; and • Monitoring Activities. • R 2. COBIT 5

R The Control OBjectives for Business and IT (COBIT ) 5 framework published R by ISACA [159] describes a generic approach to balancing goverance and man- R agement of enterprise IT in order to meet stakeholder needs [158]. COBIT 5 is an important framework because it draws together a number of other important frameworks and standards, which in addition to COSO [264] include [158]:

Balanced ScoreCard (BSC) [201] • the ISO/IEC 38500 “Corporate governance of information technology” stan- • dard [170] which is jointly issued by the International Standards Organisation (ISO) and the International Electrotechnical Commission (IEC) the ISO/IEC 31000 series of Enterprise Risk Management standards [172] • 18 the ISO/IEC 27000 series of Information Security standards [194] • R the IT Service Management standards ITIL version 3 [123] and ISO/IEC • 20000 [178, 182, 183, 177] the ISO/IEC 15504 Software Engineering Process Assessment standards [163, • 164, 165, 166, 181] Capability Maturity Model Integration (CMMISM)[348] • R The Open Group Architecture Forum (TOGAF )[273] • R Project Management Body of Knowledge (PMBOK )[306] • R PRojects IN Controlled Environments 2 (PRINCE2 )[122] • Ladley provides a comprehensive summary of data goverance [209] while Soares explores new data governance needs arising from “Big Data” and “Cloud Com- puting” [340].

The importance of corporate governance is that it drives information risk management and data governance. Information risk management and data goverance are critical dependencies for corporate governance. If information needed to support operations, reporting or compliance is incomplete, incorrect or unavailable, then the organisation’s management is not able to deliver the required outcomes.

2.2 General Legal Obligations

Although organisations diﬀer greatly in the range of laws and regulations which they are required to comply with, in general terms the following two general types of legal requirements have a strong bearing on the need for information risk management and information security testing:

1. Personal Data Protection Requirements A recent global view of data protection and trust issues is provided by [17]. Infor- mation risk management is required in order to comply with European Union (EU) data protection legislation. The 1995 EU directive on the protection of personal data [97, 98] (the EU directive) on which the UK Data Protection Act (DPA) [121] is based is itself based on the Organisation for Economic Cooperation and Development (OECD) “Guidelines on the Protection of Privacy and Transborder Flows of Personal Data” (the OECD Guidelines) ﬁrst published in 1980 [104] and most recently updated in 2013 [105] requires that a data controller “must implement appropriate measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorised disclosure or access, in particular where the processing involves transmission of data over a network, and against all other unlawful forms of processing.” [97, Art 17]. The meaning of “appropriate measures” is not deﬁned in the EU directive. However the EU directive “requires that appropriate technical and organizational measures be taken, both at the time of the design of the processing system and at the time

19 of the processing itself, particularly in order to maintain security and thereby to prevent any unauthorized processing” [97, s 46]. The same section further states that “these measures must ensure an appropriate level of security, taking into account the state of the art and the costs of their implementation in relation to the risks inherent in the processing and the nature of the data to be protected” [97]. The phrases“taking into account the state of the art” [97] and “costs... in relation to risks...and the nature of the data” [97] make it clear that organisations are required to implement and maintain up-to-date information risk management systems. 2. Records Management Standards and Requirements Electronic records management standards apply to systems which are relied upon to store, process and reproduce legally valid evidence. Hamidovic makes the important point that it is necessary to be able to demonstrate that a computer system which may be relied upon for evidential purposes has been functioning correctly because if questions can be raised about the reliability of any part of a system then the whole system may be discredited from an evidential perspective [132]. Clearly all systems which are to be relied upon for records management purposes need to be tested, both functionally and from a security perspective, before being used. Once an electronic records management system is in use, it is important to maintain complete, accurate and untamperable records of any maintenance changes made to the system, otherwise the reliability of the system can be challenged [132]. The references provided in [262, 132,2] led directly or indirectly to the following electronic records standards being identiﬁed:

ISO/IEC 27037:2012 Information technology - Security techniques - Guide- • lines for identiﬁcation, collection, acquisition and preservation of digital evidence [184];

R EU-supported MoReq2 Modular Requirements for Records Systems [109]; • BS 10008:2008 Evidential Weight and Legal Admissibility of Electronic In- • formation - Speciﬁcation [127]; BIP 0008-1:2008 Evidential Weight and Legal Admissibility of Information • Stored Electronically [330]; BIP 0008-2:2008 Evidential Weight and Legal Admissibility of Information • Transferred Electronically [146]; BIP 0008-3:2008 Evidential Weight and Legal Admissibility of Linking Elec- • tronic Identity to Documents [147]; BIP 0009:2008 Evidential Weight and Legal Admissibility of Electronic Infor- • mation. Compliance Workbook for Use with BS 10008 [331]; DoD 5015.2-STD Electronic Records Management Software Applications De- • sign Criteria Standard [88]; and Australian Standard HB 171-2003, Guidelines for the Management of IT • evidence [12].

20 2.3 Speciﬁc Legal Requirements

Security testing is required for certain types of organisations and in certain industry sectors.

Market Reporting Requirements For publicly traded companies the legal requirement to be able to detect material and report control weaknesses (i.e. if current internal controls would not detect an accidental or intentional error in the publicly reported numbers) exists both in the United States (US) and in the EU [290]. In the US any “material weakness” must be reported to the market while in the EU any material weakness may ﬁrst be reported to an internal audit committee [290]. Companies with operations in the US are subject to the Sarbanes- Oxley Act of 2002, section 404 of which requires management to assess and report on internal controls and requires external auditors to attest to and report on the assessment of internal controls made by management [317, 318]. The obligation to report any material weaknesses drives the need for testing of internal controls. This naturally includes testing of information security controls.

Payment Card Industry The Payment Card Industry Data Security Standard (PCIDSS) sets out requirements for regular security testing and sets out security testing procedures and associated guidance [69, p 89].

Healthcare Sector In the US a significant set of recommended security controls introduced as a result of the Healthcare Portability and Accountability Act (HIPAA) includes security testing and revision procedures in support of contingency planning and facility access controls for [258, p 15], [66, 65]. The importance of implementing identification and validation procedures to control who has access to software for testing and revision is specifically mentioned [65, 164.310 (2)(iii)]. In the UK NHS guidelines recommend planning security testing into the system lifecycle [287, p 14 s 3.5].

Other Regulated Sectors Based on a ten year retrospective review of US Federal Trade Commission (FTC) information security cases spanning many industry sectors including retail, software and pharmaceuticals, Breaux and Baumer identify security vulnerabilities which when exploited by attackers correspond to legal violations (including breaches of “due diligence” obligations) and corresponding security mitigations which have been agreed as legally “reasonable” [30]. In ten of the nineteen cases, application vulnerability testing was a required mitigation; and in one case network vulnerability testing and physical vulnerability testing were also required [30, p 187 table 4].

21 2.4 Summary

This chapter has established that all organisations need to implement information risk management, both to meet corporate governance requirements and to satisfy legal obligations.

For most organisations there is no explicit external requirement to perform security testing. It may be a matter of choice whether to perform security testing. If security testing is not externally mandated then the nature and extent of security testing is likely also to be discretionary.

Nevertheless in all organisations there are reasons why security testing may be required. If there is any expectation, however remote, that a system will be able to generate reliable legal evidence and/or if there is any legal or regulatory requirement to test systems, then credible functional and security testing is needed. In a legal dispute any system for which credible test evidence does not exist can easily be discredited. Since almost every organisation is required to maintain at least some records to evidential standards and since almost every organisation uses computerised databases1, almost every organisation needs to do some information security testing [Finding 1].

In organisations where the drivers for security testing are not already clear and well-understood, a strong business case will need to be developed before time and resources are allocated to security testing. One of the potential beneﬁts of a threat-based approach to security testing is that it may help to support the business case for security testing.

Before answering questions about5 “Security Testing” and6 “Threat Modeling”, the next two chapters3 and4 consider the topics of “Good Practices” and “Metadata Management” which are relevant to the enterprise context in which security testing and threat modeling take place.

1A few, very small organisations such as voluntary groups, charities and owner-managed businesses are lightly regulated and rely on manual/paper records. Such organisations are probably the only exceptions.

22 ”Using tables to store objects is like driving your car home and then disassembling it to put it in the garage. It can be assembled again in the morning, but one eventually asks whether this is the most eﬃcient way to park a car.” per [278] Esther Dyson (b. 1951) 3 Good Practices

Chapter Overview

Relationship to Goals As signposted earlier in chapter1 table 1.1 and table 1.3, this chapter explores questions arising from the second of the five goals which is “To clarify what general characteristics a framework for database security testing needs to have in order to be valuable”. This goal resulted in the following questions: Which existing good practices would it be most beneficial for the security testing • framework proposed in this thesis to be aligned with and why? What life-cycle model, if any, should the security testing framework be aligned • with? Answers to these questions define the organisational context for the “Database Security Testing Framework’ which is proposed in Part II at chapter9. During the course of answering these questions, good practice standards and frameworks are introduced which also form necessary background material for the remaining chapters of Part I, namely4 “Metadata Management”,5 “Security Testing” and6 “Threat Modeling”.

Precis of Chapter Contents This chapter identifes existing good practices which were found to be relevant including Enterprise Risk Management 3.1, Business Analysis 3.2, Data Management 3.3, Architecture Frameworks 3.4, IT Service Management Standards 3.5, Cyber Security Frameworks 3.6 and Lifecycle Models 3.7. The chapter summary 3.8 explains how these good practices feed forward into the proposed database security testing framework which is described in Part II chapter9.

3.1 Enterprise Risk Management

Enterprise risk management good practices are relevant because the primary purpose of the proposed threat-informed approach to information security testing is to improve

23 risk assessment. In the words of McCumber “a risk assessment process includes a complete operational analysis of the four major elements - threats, vulnerabilities, assets and safeguards” [225]. To facilitate integration with enterprise risk management, wherever practical this thesis endeavours to align the terminology used with ISO Guide 73:2009 which provides widely accepted deﬁnitions of risk management [173, 2.1] vocabulary. ISO Guide 73:2009 is referenced in other risk management standards including the enterprise risk management standards ISO 31000:2009 [172], IEC 31010:2009 [171] and the ISO 2700 series IT security risk management standards [186, 187] and ISO/IEC 27005:2011 [180]. The NIST SP 800-39 standard “Managing Information Security Risk” references ISO/IEC standards 31000, 31010, 27001 and 27005 [311]. Further details of risk management terminology used in this thesis are provided in the ISO Guide 73:2009 based Appendix DIV and the GlossaryIV.

3.2 Business Analysis

Business analysis techniques are relevant because the proposed threat-informed approach to information security testing is intended to validate that the most important business needs are being met. A comprehensive review of business analysis techniques is provided by Cadle et al. [37]. Of particular relevance is the observation that business analysis of Strengths, Weaknesses, Opportunities and Threats (i.e. SWOT analysis) is fed by other techniques [37, p 255], which may include:

Resource Audit [37, p 10-12] for internal strengths and weaknesses; and • Analysis of Political, Economic, Socio-cultural, technological, legal and environ- • mental factors (i.e. PESTLE analysis [37, p 3-6]) and Michael Porter’s Five Forces1 framework [37, p 6-8] for external opportunities and threats.

A common business analysis technique carried out within a business process or project involves cross-tabulating tasks with roles/individuals using a RACI matrix (or RASCI matrix) to indicate who is responsible, accountable, (supportive,) consulted and informed [37, p 79], [277, Ch 1]. This type of analysis naturally feeds into deﬁnition of required access controls.

The following standards were identiﬁed as being useful for supporting consistent capture of business requirements:

for Systems and Software Quality requirements - ISO/IEC 25010:2011 [179] • (based on ISO/IEC 9126-1:2001 [162] - see Fig 3.1) ; and

for Data Quality requirements - ISO/IEC 25012:2008 [169]. •

1per [37, p 6-8] the external Five Forces identiﬁed in Porter’s framework are: Industry Competitors, Suppliers, Buyers, Substitutes and Potential Entrants.

24 Figure 3.1: ISO/IEC 9126 Software Quality Attributes [162]

3.3 Data Management

The Data Management Body of Knowledge (DMBOK) as deﬁned by the Data Man- agement Association (DAMA) is relevant because it descrbes generally accepted good practice for data management [28]. Relationships between this body of knowledge and this thesis are explored in Part II chapter7 “Database Security Management Review”. The UK Information Commissioner’s oﬃce also provides useful advice [267, 266, 268].

3.4 Architecture Frameworks

Enterprise Architecture Frameworks Enterprise Architecture (EA) frameworks are relevant because they help to translate organisational strategies into actions and assist with the planning and execution of current state to target state transitions. The EA frameworks which I have observed being referenced most frequently are:

Zachman Framework [377] • R The Open Group Architecture Framework (TOGAF )[273, 274] • US Department of Defense (DoD) Architecture Framework (DoDAF) [89] • UK Ministry of Defence (MOD) Architecture Framework (MODAF) [243] • An approach to simplifying EA using partitioning is proposed by [326]. Relationships between MODAF, DoDAF, TOGAF and Zachman are described by [242]. Widney sug- gests an optimal order for the creation of DoDAF Operational View (OV) artefacts [368, p 14] and System View (SV) artefacts [368, p 29]. Changes to DoDAF and MODAF are

25 coordinated through [128]. A summary of terminology and structural changes introduced by DoDAF version 2.02 is available at [89, p 107].

Security Architecture Frameworks A good overview of enterprise architecture frameworks focusing on security architecture development is provided by [195] The process-oriented Open Information Security Management Maturity Model (O-ISM3) describes progressive improvements to security control processes [86]. A service-oriented approach to security architecture, which R references the proprietary Sherwood Applied Business Security Architecture (SABSA ) framework [329, 133], is described by [288]. However the following three-tier view of security architecture provided by [350] was initially considered as a potential basis for the proposed security testing framework:

Enterprise Security Architecture • Application Security Architecture • Product Security Architecture • For reasons which are further explained at section 3.7 and in chapters6 and9, this thesis splits the Enterprise Security Architecture tier between:

Organisation - External Security Architecture - focused on external security threats; • and

Zone - Internal Security Architecture divisions - needed to manage internal security • threats and residual external threats.

3.5 IT Service Management

Service management is relevant [Decision 1] because:

databases provide services to other applications and direct to users; • databases consume infrastructure services; • databases may consume services from other databases and from other applications; • delivering database services depends on supporting database administration (DBA) • services;

performing security tests involves the provision of testing services; and • performing security tests impacts the timescales, costs and quality of delivering • other services.

26 Three signiﬁcant sources of IT Service Management guidance are the IT Infrastructure R Library (ITIL ) v3 [123] developed by the UK Government’s Oﬃce of Government Commerce (OGC), the ISO/IEC 20000 series of IT Service Management standards [178, R 182, 183, 177] which are based on ITIL [277, Ch 1] and the Skills Framework for the Information Age (SFIA) version 5 [112]. Perhaps the most important contribution of IT service management frameworks is their emphasis on alignment between business services and the technical services on which R they depend [277]. The following diagram from ITIL v3 summarises this important contribution:

Figure 3.2: ITIL Service Catalogue per [279, p 76 ﬁg 4.4]

3.6 Cyber Security Frameworks

Cyber-threats are not exclusively information centric. Threats to information assets may merely be incidental to broader threats against people and physical assets. Cyber-security frameworks emphasise the need to mitigate the threats that arise from the combined eﬀects of having connections to the internet and having information, people and physical assets which need protection. Several governments have published cyber security advice including: UK government [50, 49, 48]; • Australian Signals Directorate (ASD) Top 35 controls [44]; • US National Institute of Science and Technology (NIST) [265]. • 27 The ASD Top 35 controls [44] are noteworthy because:

1. the Top 4 controls (software whitelisting, application patching, operating system patching and minimising administrator privileges) are reported as reducing cyber incidents by 85 percent;

2. each ASD control is categorised according to which phase of a targeted cyber- intrusion it is eﬀective against (Stage 1 Code Execution, Stage 2 Network Prop- agation, Stage 3 Data Exﬁltration); and

3. the controls are periodically re-ranked by ASD in descending order of priority according to the latest available assessment of their eﬀectiveness.

Although some ASD cybersecurity controls will be further discussed, the structure of the NIST cybersecurity framework [265] proved to be more relevant to the proposed database security testing framework [Decision 2] for three reasons:

1. It defines five high level security control functions (identify, protect, detect, respond and recover [265]) which reflect natural sequence dependencies in the establishment of security controls i.e. identify is needed before protect, detect before respond etc;

2. Both the ﬁve high level security control functions and the more detailed underlying security control categories [265, p 22-37] represent meaningful generic security test objectives;

3. NIST and others [1] have taken the trouble to cross-reference this framework to R a number of other important frameworks including COBIT 5 [158], NIST SP 800-53 [308, 309] and ISO/IEC 27001 [186].

3.7 Lifecycle Models

Maturity Models Maturity models associate the introduction of testing processes (including evaluation and validation) with the transition from maturity level 1 (initial) to maturity level 2 (managed) [348, 86, 362].

Service Management Lifecycles

R In the ITIL lifecycle model Service Strategy is concerned with enterprise planning and considers organisational boundary issues i.e. which services to perform internally and which services to outsource; Service Design involves the creation of service models and service descriptions using combinations of people, processes, products (technology) and partners(suppliers); services are implemented during the Service Transition phase; many service management activities are required during the Service Operations phase; while Service Improvement involves making measurements and assessing the eﬀec- tiveness of changes [123, 277]. “Service Validation and Testing” is one of the processes

28 R within “Release, Control and Validation” (RCV) which occurs within the ITIL Service Transition phase [277]. However security testing may be needed at diﬀerent stages of this lifecycle. Risk management, which includes analysis of threats, occurs throughout the service management lifecycle but is particularly emphasised in the Service Strategy phase [123, 277].

Systems and Software Development Lifecycles Reviews of widely-used software lifecycles are provided by [93, 249, 313, 21]. Good practice security lifecycles are described by [52, 260, 233, 102, 234]. Whilst accommodating other lifecycle models, the testing framework proposed in this thesis is a modification of the V-model (originally “Vee-model” and later “Vee++ model”) for systems development lifecycles which grew the North American Space Agency (NASA) space shuttle program [107, 108, 246][Decision 3]. Although not a fully iterative process, latest in- carnations of the V-model emphasise user involvement at all stages, feedback from later stages to earlier stages and iterative improvements within phases at different architecture layers [313, 246]. The V-Model is particularly useful as a basis for testing frameworks because it involves the following two passes: 1. from top to bottom as the testing framework2 is developed (strategies, scenarios, test cases, logs, etc.) [139, p 168]; and 2. from bottom to the top as tests developed during the first pass are executed [139, p 168]. The V-Model is also extensible with additional stages for more complex systems and supports a z-axis for components associated with multiple deliveries, allowing time to be represented by two axes: from left to right for progress of each separate components and into the plane for components at different stages [313, p 10]. There are several further reasons for aligning with this model: security testing is an activity which needs to be formally scoped and approved; • security testing is often part of a “gate” process i.e. until security testing is • successful, systems should not be approved for operational use; there are high level sequence dependencies in testing e.g. test environments • need to be security tested before they are relied upon; within each phase of testing, there are natural sequence dependencies between • the order in which security controls need to be tested; and there are natural sequence dependencies between architecture components e.g. • infrastructure before databases, single databases before multiple databases. The initial concept for the proposed security testing framework, which is modified and explained in chapter9, is based on the V-Model.

2The term “testing framework” as used by [139, p 168] refers to a project-speciﬁc instance rather than a reference model testing framework such as that described in chapter9.

29 Table 3.1: Initial V-Model Based Concept for Database Security Testing Framework

Preceding Testing Database Security Testing Subsequent Testing a. Initial Organisation Security k. Full Organisation Security b. Initial Zone Security j. Full Zone Security c. Initial Integration Security i. Full Integration Security h. Service security g. System security f. Interface security e. Infrastructure security d. Product Security

Three modiﬁcations to the V-Model reﬂected in table 3.1 are that:

1. initial security testing of architecture layers above the database tier is performed prior to the left-side of the “database security testing” V-Model;

2. all security testing of architecture layers below the database tier is performed prior to the left-side of the “database security testing” V-Model;

3. the completion of security testing of architecture layers above the database tier is performed after the right-side of the “database security testing” V-Model;

There are several reasons for positioning database security testing in the middle of more broadly scoped security testing:

1. it is more eﬀective to apply and test security controls at higher levels - maximising the security separation between threats and assets;

2. it is more eﬃcient to apply and test security controls at higher levels - security process costs applied at higher levels protect more assets against exposure to threats and reduce the total amount of security testing required;

3. architecturally databases sit in the middle of the technology stack, with higher level and lower level dependencies;

4. it would be wasteful to start database security testing before upward and downward security dependencies had been satisﬁed;

5. it would be wasteful to perform higher level testing of enterprise integrations before the security of database services has been assured through testing; and

6. if higher level controls do not adequately protect database test environments then database security test evidence cannot be relied upon.

30 3.8 Summary

This chapter has explained why good practices for Enterprise Risk Management 3.1, Business Analysis 3.2, Data Management 3.3, IT Service Management 3.5 and Cyber Security 3.6 are relevant to security testing of database systems. The reasons for aligning the lifecycle of database security testing with the V–model have also been briefly explained 3.7. Having identified broad good practice standards and guidelines which influence the context for security testing, the next chapter4 will explore a topic much more closely related to databases, namely Metadata management.

31 32 “Metadata promises too much value as a business management tool to dismiss its implementation and maintenance eﬀort as the equivalent of Sisyphean torture.” per [328, p 89] Ganesan Shankaranarayanan & Adir Even 4 Metadata Management

Chapter Overview

Relationship to Goals As signposted earlier in the chapter1 “Introduction” table 1.1 and table 1.3 and in the previous chapter3, this chapter covers the remaining research questions arising from the second goal which is“To clarify what characteristics a framework for security testing of databases needs to have in order to be valuable”. This chapter focuses specifically on answering the following questions: What are the prerequisites for effective control of database security? • What do all organisations need to know about their data regardless of what • databases they use? The material introduced in this chapter is useful background for the next chapter5 “Security Testing” and the following chapter6 “Threat Modeling” which together complete Part I by answering the remaining questions related to the first goal. This chapter is also particularly relevant to Part II chapters7 and8.

Precis of Chapter Contents This chapter starts with an explanation of why a minimum level of metadata management is a prerequisite for database security 4.1, an explanation of the value of metadata 4.2, the history of metadata 4.3 and an exploration of metadata classiﬁcation 4.4. This leads into a brief introduction to metadata security 4.5 before drawing conclusions 4.6 which feed forward into later chapters.

4.1 Prerequisites for Database Security

Quite simply an organisation is not able to secure its database systems if it is not able to answer any of these questions: why data is being stored? • 33 what database assets does the organisation own? • how much data is the organisation responsible for? • which jurisdictions govern the data asset locations? • what data is stored in which database? • what value does the organisation place on its database assets? • how long does data need to be retained? • who is responsible for each database? • when, where and why does each database need to be available? • when was each database last backed up? • What these questions have in common is that they are all questions about data. Answers to these questions are metadata i.e. data about data. Good explanations of the importance of data deﬁnitions are provided by [144, Ch 6], [222]. It may not be necessary for the full meaning of every data item to be tracked, but all organisations need a minimum level of reliable metadata to be able to identify, secure and extract value from data.

4.2 Value of Metadata

In addition to being necessary for security, metadata plays a signiﬁcant role in the data value chain as described by Miller [238].

Figure 4.1: Data Value Chain per [238, p 58 ﬁg 1]

There are natural sequence dependencies in extracting value from data [238]: building an inventory of data sources and metadata; then • enabling access to data sources and setting up access-control rules; before • 34 organising, integrating and exploiting data. • Beneﬁts of metadata cited by [327] include: more eﬃcient searching; preserving data integrity; tracking usage patterns; application-independent data management1; and data redundancy control2.

4.3 Metadata History

McComb’s brief history of metadata describes an evolution from passive, static metadata (e.g. retrospectively documenting ﬁelds used by an application in a data dictionary) to actively managing metadata and making provision for metadata to change [222, p 87- 93] which accords with Sen’s summary of how metadata management approaches have developed since the 1960’s [325]:

Stage I - Implicit metadata management • Stage II - Co-management of metadata • Stage III - Explicit metadata management • Stage IV - Metadata integration management • Veryard’s descriptions of how to coordinate diﬀerent approaches to managing metadata and models simultaneously remain relevant [356, 357].

4.4 Metadata Classiﬁcation

Metadata can be classiﬁed by structure, functional usage, lifecycle, levels of abstraction and meaning.

Structural Classification of Metadata Traditional databases use Data Definition Language (DDL) to define data structures [220], [76, p 33]. From a logical perspective DDL is metadata. Physically DDL is executable code located and controlled separately from the data structures it creates. Data stored in databases controlled by DDL is not self-describing. Over the years, particularly since the advent of Structured Generalised Markup Language (SGML) [160] and eXtensible Markup Language (XML) [29] there has been a trend towards greater use of “self-describing” data formats in which metadata is stored with data. In order to facilitate metadata management of internet resources, metadata formats such as XML Topic Maps (XTM) [283], Resource Description Framework (RDF) [237] and Linked

1Date also uses the concept of “Data Independence” from applications [76, p 16-21] as part of the justiﬁcation for the relational database model. Depending on how metadata is managed, metadata may provide more or less data independence than the relational model. 2Although storage costs are constantly falling, data volumes and data management costs are constantly rising so the economic drivers are still present for data normalisation, which reduces redundancy as explained by Codd [55], Date [74], Martin [220] and many others.

35 Object Data [212] have been developed. RDF allows descriptive statements to be made about arbitrary resources using a standard metadata format consisting of a subject (S), predicate (P) and object (O) triple [237, 95]. To aid human understanding of information it is necessary to document Conceptual Data Model (CDM) and Logical Data Model (LDM) views, in addition to the Physical Data Model (PDM) view [220, 356, 357, 144, 142].

Functional Classiﬁcation of Metadata

Earlier functional classiﬁcations of metadata [204, 218, 150] have been built upon by [327, 328] to propose the following 6 functional groups of metadata:

1. infrastructure

2. model

3. process

4. quality

5. interface

6. administration

Essentially infrastructure metadata abstracts the tracking and management of hardware, software and network components so that they are not hard-coded; model metadata abstracts the management of data dictionaries and data mappings, including the cardinality of relationships between data items, and semantic equivalence relationships; process metadata abstracts how data is generated, transformed and moved internally; quality data abstracts data quality measurements including record counts, data size information and accuracy and completeness metrics; interface metadata abstracts the format and timing of how information is presented to users and other sytems; and administration metadata abstracts security control, system management and resource usage tracking.

Two specialised functions of metdata merit particular attention:

Architectural Metadata

An important subset of model metadata is architectural in nature. Both DoDAF and MODAF can be described using formal meta models, the DoDAF Meta Model (DM2) [89, p 22] and the MODAF Meta Model (M3) [244] both provide a degree of support for Universal Modeling Language (UML) [89, p 92], [243] although UML does not fully support the IDEAS meta model [89, p 37]. System designs may be modeled using SysML [135].

36 Security Metadata An important subset of administrative metadata is security metadata. Metadata related to reliable exchange of threat information is particularly important [26, 72, 11]. Examples include:

the MITRE.org standards Structured Threat Information eXpression (STIX) [14] • and Trusted Automated eXchange of Indicator Information (TAXII) [67];

this 2013 paper on Security Event Information Management (SIEM) which includes • an Attack Modeling and Security Evaluation Component (AMSEC) [206];

Operational access controls may also be mediated through security metadata including Lightweight Directory Interchange Format (LDIF) [120], Security Assertions Markup Lan- guage (SAML) [57] and eXtensible Access Control Markup Language (XACML) [248].

Classification of Metadata by Lifecycle Metadata may be prescriptive (i.e. defined before data is processed) or descriptive (i.e. as a result of data analysis) [222, Ch 6]. Descriptive metadata (e.g. data quality metrics and administrative statistics) cannot be mandated. However processes which generate descriptive metadata require some prescriptive metadata as inputs and may also require some descriptive metadata outputs from previous operations. Without appropriate metadata inputs, automated data processing is unreliable, inefficient or both.

Classiﬁcation of Metadata by Abstraction Levels Data - concrete, no abstraction. If abstraction levels are ignored, any level of data • or metadata may be treated as data.

Metadata - ﬁrst meta level (M1) descriptions of data [292]. May support any or • all of the above-described functions [327, 328].

Meta-Metadata - second meta level (M2) descriptions of meta-data [292], [252, • p 42]. This level of abstraction can be used to develop mappings between metadata models and to track the provenance of metadata [95].

Meta-Meta-Metadata - third meta level (M3) descriptions of meta-metadata • [292], [252, p 42]. This level of abstraction supports management of diﬀerent meta-metadata models [292].

Semantic Metadata The need for semantic metadata is widely recognised [54, 79, 95, 141, 339, 18]. A business-oriented introduction to metadata by McComb [222, Ch 6] makes a strong case for metadata-driven application architectures, explaining that most semantics live in metadata and highlighting that:

37 Universal Modeling Language (UML) builds on and incorporates the Meta Object • Facility (MOF) [222, p 95]

the MOF is essentially the metamodel for software architectures [222, p 95] • standards exist to allow conversions between metadata formats, speciﬁcally XML • Metadata Interchange (XML) [222, p 95] (the latest version of which is [272]) and Common Warehouse Metamodel (CWM) [53] (the latest version of which is [271]).

McComb explains the importance of early testing to validate semantics [222, p 113].

4.5 Metadata Security

Since metadata is involved in such a broad range of functions, keeping metadata secure is clearly important. Three points about metadata security that merit particular attention are that:

there is no clear dividing line between data and metadata: depending on imple- • mentation decisions data may be stored as metadata and metadata stored as data;

diﬀerences between the security controls applied to data and the security controls • applied to metadata may be exploitable;

boundaries between data contexts (whether between data and metadata, or be- • tween one type of data and another type of data) are frequently exploitable.

Much of the work of penetration testers relies on identifying how data is being parsed by interpreters, understanding grammars of software languages which may cause data in grammar A to be interpreted in grammar B and subsequently creating valid phrases in grammar B that can be executed via grammar A [371, p 11]. Metacharacters which mark logical context switches are often exploitable [91, Ch 8].

4.6 Summary

Metadata matters because data can be stored and processed in many ways. Metadata describes and prescribes how data is stored and processed. Therefore ensuring the security of data (including availability, integrity, conﬁdentiality, authenticity, provenance and many other security attributes) is intimately dependent on how well the associated metadata is managed 4.1. Adding value to data relies both on knowing how it is stored and on the manner in which it is being stored being compatible with the intended use 4.2. A short review of metadata history 4.3, metadata classiﬁcation 4.4 and metadata security 4.5 makes it clear that there are no easy answers as to how best to manage metadata. Nevertheless it is important that the proposed security testing framework should address the topic of metadata management (Decision 4).

38 This chapter’s exploration of metadata management taken together with the previous chapter3 has helped to clarify which existing good practices the proposed security testing framework proposed should be aligned with and why i.e. answering questions arising from research goal two 1.3. The next chapter5 “Security Testing” picks up questions arising from research goal one 1.2 which were not answered in chapter2 “Enterprise Information Governance”.

39 40 “Truth is what stands the test of experience.” per [39, p 452] Albert Einstein (b. 14 March 1879, d. 18 April 1955) 5 Security Testing

Chapter Overview

Relationship to Goals As signposted earlier in chapter1 table 1.1 and table 1.2 and in chapter2, this chapter considers further questions arising from the first goal which is “To explore reasons why threat-based security testing may be needed”. This chapter focuses specifically on answering the following questions: What is security testing? • How does it relate to other types of testing? • When is security testing needed? • What can security testing measure? • How can security testing be improved? • The remaining questions arising from the first goal are considered in the next chapter6 “Threat Modeling”.

Precis of Chapter Contents Chapter3 described good practices which could inﬂuence the context in which security testing occurs. This chapter describes security testing in a context-neutral manner starting with an overview of security testing 5.1, a description of how security testing relates to software quality assurance 5.2 and explanation of security test planning 5.3. Ideally security testing should occur throughout the lifecycle 5.4, however security testing is particularly necessary before a test subject1 is exposed to new threats. Security testing techniques 5.5 and security testing methodologies 5.6 are described before discussing security testing challenges and opportunties 5.7 and drawing conclusions 5.8.

1for brevity the generic term “ test subject” will be used to describe the “software, system or services which depend on technology” the security of which is being tested. If security testing of physical or human targets is being discussed then additional words will be used to make this clear.

41 5.1 Security Testing Overview

Security testing involves a significant commitment of resources. It may involve the use of techniques which if not correctly authorised would potentially be contrary to criminal law. Even planning how to mount an attack without permission could potentially amount to conspiracy to commit a criminal offence. It is therefore essential for the high level scope of security testing to be defined and authorised before any testing takes place.

Security testing eﬀort is generally directed at one of these subjects:

environmental controls including physical security controls (e.g. [7]) and personnel • security controls (e.g. [134]); or

IT system technical controls e.g. [213, 365, 269, 320, 232, 233, 369, 260]. • One of the objectives of security testing is to validate that security controls have been implemented with few or no vulnerabilities, including vulnerabilities that have been iden- tiﬁed by threat modeling [232, p 25]. For systems which have no outside network connections, testing environmental controls alone may provide adequate evidence of security without testing any technical controls. The converse is not true: only testing technical controls cannot prove that information is secure - because information security breaches could still occur through breaches of physical and/or personnel security. Professional Penetration Test (PT) engagements may, with appropriate prior permissions, include tests of physical security and human security [15, 138]. However in my experience, organisations rarely perform physical, personnel and technical security tests simultaneously.

IT security testing specialists tend to focus on one of three broad types of testing:

laboratory-based security testing of software and hardware products; • in-situ infrastructure security testing of networks, operating systems and hardware; • in-situ security testing of software applications. • While this thesis identiﬁes needs for all types of security testing (including testing of physical and personnel security controls), since database systems are reliant on software and since the majority of attacks on databases target software applications, the main focus is on guiding in-situ security testing of database software applications.

5.2 Software Quality Assurance

Stakeholder Expectations Stakeholder expectations of software quality assurance vary greatly. As a result the process of testing software may be performed with diﬀerent aims in mind:

attesting that software functions as expected [284, p 325] • 42 giving “confidence that a program functions according to its specification” [130] • finding as many defects as possible [130] • key approach to risk-mitigation in software development [190, Abstract] • while officially acting as customer “surrogates ... attempting to faithfully replicate • customer use of a system ... unoffically ... incessantly making implicit decisions about what customers would and wouldn’t do” [361, 11.2.5]

Since stakeholders with different perceptions of quality have different expectations of testing [361, 1.2.1], different test types are expected. One of the major challenges in software quality assurance is that many stakeholders do not understand that exhaustive testing is not viable (either in terms of costs or timescales) except for the simplest of systems [130, Ch 1], [367, Appendix C]. It is likely that a wide range of other software quality assurance processes will remain important (e.g. [115, 360, 364, 362, 291]). Brief descriptions of the more frequently encountered software test types are included in the GlossaryIV. A considerable effort to standardise software testing is summarised in Appendix EIV. However software security testing is not fully addressed by current international standards for software testing. Neither is database testing or database security testing [Finding 2].

Risk-Based Testing Since exhaustive software testing is not normally viable, software quality assurance tests are generally planned using a risk-based approach. ISO/IEC 29119 adopts a risk-based approach to testing [190, 299] and provides a generic process model which it is intended can be used with any software development life cycle [299].

Software Testing Terminology The following software testing terminology is highlighted because it is also relevant to security testing:

static testing - testing of an object without execution on a computer [154, 5.173]; • dynamic analysis - the process of evaluating a system or component based upon • its behaviour during execution [154, 5.80];

white box testing - also known as “Full Knowledge Testing” [156, p 41], “Struc- • tural Testing” [131, p 30] and Comprehensive Testing [156, p 41] is performed with full accesss to all available information about the test subject i.e. including requirements, design, external interfaces, internal structure and results of previous testing;

43 black box testing - also known as “No Knowledge Testing” and “Functional • Testing” is performed with no information about the internal design of the test subject and may be sub-categorised into Speciﬁcation-based Testing and Opera- tional Testing [131, p 30], [367, p 174].

5.3 Security Test Planning

The nature of security testing depends upon the nature of the assurance required. Risk- based testing approaches are often recommended [370, 225, 296, 136, 168, 310, 233]. A combination of positive and negative testing is often needed. Positive Testing is designed to generate evidence of correctness while Negative Testing is designed to generate evidence of failures. Without any positive testing there is no evidence of correct functionality. Without any negative testing there is no evidence of the extent of latent defects. When performing negative tests, an absence of evidence can be a positive result.

For any given functional scope of testing, the extent of security testing required depends on the:

required security properties [174, 167, 168, 200, 304]; • degree of assurance required [87, 64, 174, 167, 168, 198, 304, 24]; and • level of uncertainty i.e. potential for errors in risk assessments [198]. • Whenever more security assurance is required or there is more uncertainty, more security testing is required whether the uncertainty concerns the subject of the security test, the threat environment or both. If a test subject is small, simple and well documented there is minimal uncertainty about the risks of the security test subject. If the test subject is composed only of known components which have been previously tested individually but not tested in combination, then there is a moderate degree of uncertainty about the risks of the test subject. If the test subject is a large and complex system which is still being developed, then there is great uncertainty about the risks of the test subject.

5.4 Timing of Security Testing

There is broad consensus that software testing [223, 149]and security testing [118, 145, 205, 232, 102, 228, 234] should start early and continue repeatedly throughout the lifecycle. The earlier that testing is performed the greater the potential to avoid the costs of software defects [223] and security defects [145]. Security test evidence generated throughout the lifecycle can be used to show that delays which would otherwise have occurred have been avoided [232, p 37]. Security test metrics can be used to demonstrate compliance and to support informed investment decisions [232, p 37]. NIST recommends that organisations develop “an information security assessment policy...” [which] “...should address:

organisational requirements with which assessments must comply; • 44 appropriate roles and responsibilities (at a minimum, for those individuals approving • and executing assessments);

adherence to established methodology; • assessment frequency; and • documentation requirements, such as assessment plans and assessment results” • [320, p 42 s 6.1].

This thesis extends the NIST position on the importance of organisations developing a security testing policy, by arguing that:

the timing and scope of security testing should take account of threats; • test evidence from diﬀerent types of security testing should be integrated, used • to update threat models and retained securely as part of the audit trail for the correct operation of the test subjects.

This thesis also argues that there are particular points in the lifecycle of any test subject when it is particularly important to capture adequate security test evidence before proceeding. These points occur before the test subject is exposed to new threats which it has not previously been demonstrated (through earlier security testing) to be able to withstand. One of the major contributions of threat modeling to security testing is to track what threats test subjects have been proven to be able to withstand and what threats test subjects have not yet been proven to withstand. This helps to clarify when additional security testing is needed.

5.5 Security Testing Techniques

Positive Testing Positive security testing is very similar to non-security related software testing. It generates evidence of correct security functionality under deﬁned test conditions. Positive security testing can be performed using black-box or white-box techniques and using both static analysis and dynamic testing methods.

Negative Testing Negative security testing is intended to generate evidence of security failures. Classiﬁca- tion of negative security testing techniques is a little more complex2. Negative security testing can be divided into black-box testing, white-box testing and grey-box testing. As with positive white-box testing, negative white-box testing is performed with full

2The Open Source Security Testing Methodology Manual (OSSTMM) describes six different types of offensive (negative) security testing depending on the degree of knowledge on the part of the testers and the degree of knowledge on the part of the people responsible for maintaining [138, p 37]. However the OSSTMM security test classifications are not used by other frameworks, so more widely accepted definitions are used here.

45 knowledge of the test subject. Eﬀective negative white-box testing can be performed using both static and dynamic methods. As with positive black-box testing, negative black-box testing is performed with no prior knowledge of the test subject. However negative black-box testing is diﬀerent from positive black-box testing, because security testers (acting as simulated attackers) are interested in discovering internal details of the test subject to the extent that they facilitate exploits. Internal details are of no interest when performing positive black-box tests. Negative Black-Box Test testing, which may be described as Basic Testing [156, p 57], falls into two main sub-categories:

Vulnerability scanning (VS); or • Penetration Testing (PT). • VS is a relatively inexpensive negative “Black-Box” testing technique because it does not require significant investment in discovery. However VS alone cannot discover complex attack chains. PT is a far more powerful negative “Black-Box” testing technique which can, if expertly performed, provide the most realistic representation of what an attacker would be able to do. PT techniques can be traced back at least as far as Linde’s 1975 paper on using Flaw Hypothesis Methodology (FHM) for operating system penetratation [213]. However PT is significantly more expensive than “White-Box” testing because it requires the tester independently to perform discovery to build up knowledge of the system. Grey-box testing, which is also described as “Partial Knowledge Testing” [138, p 37] and Focused Testing [156, p 57], is particularly effective for testing internal controls: authorised testers are provided with a limited amount of access and knowledge and asked to determine whether it is possible to breach internal controls to escalate their privileges.

Discussion of Security Testing Techniques Each of these techniques has strengths and weaknesses. Positive and Negative white- box security testing provides comprehensive insight into all aspects of a system, while avoiding the costs of discovery. Negative black-box testing provides insight into what potential attackers could do. It is not meaningful to perform negative static analysis on a black-box or grey-box basis, because without full (white-box) access to information, static analysis test results will be incomplete. Negative grey-box testing, based on white- box security threat modeling, provides unique insight into the effectiveness of internal controls and is critical for testing the effectiveness of separation of duties between normal database users and database administrators. One of the potential benefits of using threat models to guide security testing is that it may be possible to increase the proportion of security testing being performed using lower cost white-box techniques whilst improving the quantity, quality and timeliness of information which would otherwise have been obtained using expensive PTs. Based on this analysis in order to address the wide range of threats to database systems, an integrated approach to security testing is needed which includes white-box, black-box and grey-box techniques [Finding 3].

46 Security Testing Logistics Regardless of the types of security testing technique being used, security testing relies on excellent conﬁguration management [174, s 3.4.7, 5.2.2], versioning [68] and change control [123] processes being in place spanning the entire scope of the security testing. Without robust conﬁguration controls, security test processes will not be repeatable and test evidence will not be reliable.

5.6 Security Testing Methodologies

Product Security Testing Formal security testing of products always involves full disclosure of design and implementation details and therefore falls into the “White-Box” testing category. Positive and negative security testing techiques are required. The US Department of Defense (DoD) has for many years required security testing. The 1985 Trusted Computer Systems Evaluation Criteria (TCSEC) describes three high level control objectives (Security Policy, Accountability, Assurance) and a supporting control objective (Documentation). These control objectives drove the need for lower level security objectives such as the three basic design requirements for the “reference monitor” concept which was required: to be tamperproof; • always invoked; and • small enough to be subjected to analysis and tests, the completeness of which can • be assured. DOD5200.28-STD [87]. TCSEC and ITSEC [64] led to the development of the Common Criteria [61, 60, 62] scheme, which has resulted in the ISO/IEC 15408 security evaluation criteria standards [174, 167, 168]. Although there have been criticisms of the CC scheme (e.g. [293]), while developing the proposed security testing framework, aspects of the Common Criteria scheme have been relied upon in particular: the philosophy “that the threats to security and organisational security policy • commitments should be clearly articulated and the proposed security measures be demonstrably sufficient for their intended purpose.” [168, s 5.1]; the definitions of testing terminology [174]; • the need for security controls in development environments [168, s 13.4]; • the need for configuration control over test subjects [174, s 3.4.7, 5.2.2]; • the need for metadata which affects the security of systems under test to be version • managed and auditable [167, s 12.3]; the Protection Profile (PP) details for database products [80, 59, 84, 85]; and • the manner in which CC testing of database security products deals with the various • interfaces through which database software communicates with its environment.

47 Enterprise Security Testing Guidance on combining sources of assurance including product assurance is provided by [200, 304]. The sources which were found to be most relevant while developing the proposed security testing framework were the OWASP Testing Guide v3 [232], NIST SP 800-30 Revision 1 Guide for Conducting Risk Assessments [310] and NIST SP 800-115 Technical guide to Information Security Testing and Assessment [320].

Aspects of the following enterprise security reference, not all related to testing, have also proved helpful:

Information Systems Security Assessment Framework (ISSAF) [138]; • Open-Source Security Testing Methodology Manual (OSSTMM) [269]; • Software Assurance Maturity Model (SAMM) [52]; • NIST SP 800-53A Guide for Assessing the Security Controls in Federal Information • Systems: Building Eﬀective Security Assessment Plans [156];

NIST SP 800-144 (Draft) Guidelines on Security and Privacy in Public Cloud • Computing [196]; and

Department of Homeland Security (DHS) Security Testing Articles [260]. • Model-Based Security Testing & Test Automation Testing based on FHM [213, 211] is model based. The concept of model-based test automation is also not new: automated black-box functional testing based on speciﬁcations was described in 1999 by [114]. Model-based (but not threat model based) automation of database security testing was described by Blackburn in 2001 [23]. Threat-model based automated security testing is described by [375, 359].

5.7 Security Testing Challenges & Opportunities

Before concluding on security testing, it is important to mention some of the general challenges in security testing and ways in which they may be improved.

Security Measurements and Metrics Security testing is a process which generates measurements. Ideally security testing measurements should be accurate, valid and repeatable. The challenges of making security measurable are described by a number of sources including [221, 319]. Payne [285, p 2] citing Jelen [197] makes the following important distinction:

‘‘Measurements provide single-point-in-time views of specific, discrete factors, while metrics are derived by comparing to a predetermined baseline two or more measurements taken over time.’’

48 Unfortunately, in my experience, many security test measurements are not collected in a manner than allows meaningful time-series analysis and the generation of metrics. MITRE corporation have made measurable security a particular focus and assert that [240] measurable security should, as a minimum, cover:

Software Assurance • Application Security • Asset Management • Supply Chain Risk Management • Cyber Intelligence Threat Analysis • Cyber Threat Information Sharing • Vulnerability Management • Patch Management • Conﬁguration Management • Malware Protection • Intrusion Detection • System Assessment • Incident Coordination • Enterprise Reporting • Remediation • This thesis does not attempt to address all aspects of security measurement, but does aim to propose a high level structure which will allow a wide range of security measurements including those identﬁed by MITRE to be made.

Economics of Security Testing Security testing is a very expensive and time-consuming process. Ideally as much security testing as possible would be automated so that it could be completed more quickly and with less human input. However the complexity of modern environments and the risk that automated security testing tools could themselves be exploited present signiﬁcant barriers to test automation. A potential area for improvement is metadata quality and security. To the extent that the completeness, accuracy and timeliness of metadata management can be improved and the security of metadata better protected, it may be possible to increase the proportion of automated security testing.

49 Pervasive Security Properties Some security properties such as integrity and non-repudiation are pervasive. For such properties, demonstrating reliable functionality of the whole requires positive evidence and sustained comprehensive configuration control over all components. As mentioned earlier if the reliability of any part of a system can be questioned for any time period then the whole system may be discredited from an evidential perspective [132]. Pervasive security properties cannot easily be allocated to particular locations, sub-systems or components, tested in isolation at different times and places and then brought together to be tested in combination. Pervasive requirements are difficult and expensive to test because all testing needs to be carried out at a much larger scale, firstly at system level and then at “system of systems” level for systems which interface with others. This thesis makes the case that it may be possible to improve the quality of security test evidence and reduce the cost of generating security test evidence if: 1. the sequence and scope of security testing takes better account of threats; 2. the environment in which database testing is performed is itself tested and fully secured before database testing begins; and thereafter configuration-controlled and version managed throughout database security testing [Decision 5]; 3. an integrated approach to security testing is needed, including white-box positive testing, white-box negative testing (including threat modeling), grey-box negative testing and black-box negative testing [Decision 6].

Special Problems with Database Security Testing Most application software does not directly control access to data, relying either on the operating system to provide file access or a database. This means that most software can be tested without putting real information at risk. Databases are different because, for most of their operating lifetime, they will store and process real data. Full database functionality cannot be tested without real data. Therefore database security is not something that can be tested in a fully iterative, incremental manner. At some point a decision has to be made about whether a test database environment which has not yet been fully tested, because it has not contained any live data, is sufficiently secure to be used with live data. This decision is not reversible. Once live data is being used for testing, the database must be treated as live. Any security incident involving live data must be treated as a real one, even it occurs in a test environment which is not fully exposed to the same threats as the production environment. One of the ways in which it may be possible to improve database security testing is by better management of threats that arise during the late stages of testing, when it is necessary to use real data. However perhaps the best way to improve database security testing is by making threat-based testing more realistic without any risk to live data. Possible ways of doing this include: 1. use of synthetic (lab) environments to simulate threats & defences [24, 369]; and 2. controlled live use of carefully designed and configured test databases as honeypots [342, 45].

50 Provided that precautions are taken to ensure that test systems being exposed to attackers do not provide attackers with any information that might be useful for attacking real database targets (e.g. using totally different network ranges, different field names, different field lengths, no live data etc) , it may be possible to expose the next N3 versions of database software directly to potential attackers. However being able to generate synthetic test database environments and honeypots depends on extremely good metadata management4.

5.8 Summary

This chapter has provided an insight into what security testing is 5.1, how security testing relates to software quality assurance 5.2 and the most important aspects of security test planning 5.3, 5.4. It has also introduced important security testing techniques 5.5 and methodologies 5.6. Some general challenges for security testing have been identiﬁed 5.7 along with potential improvements. The next chapter6 which marks the end of Part I “Enterprise Context”, introduces the subject of “Threat Modeling”.

3Based on principles described by [82, 40, 148, 24] defenders should be expecting to be attacked and have pre-tested versions of software ready to deploy.

51 52 If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suﬀer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. Sun Tzu “The Art of War” [353]) 6 Threat Modeling

Chapter Overview

Relationship to Goals As signposted earlier in chapter1 table 1.1 and table 1.2 and in chapters2 and5, this is the final chapter of Part I “Enterprise Context”. It examines the final group of research questions arising from the first goal which is “To explore reasons why threat-based security testing may be needed”. This chapter focuses specifically on answering the following questions: What is Threat Modeling? • Why is Threat Modeling valuable? • Are there different approaches to Threat Modeling? • What are the most appropriate levels of granularity at which to perform TM? • Precis of Chapter Contents This chapter starts by explaining what Threat Modeling (TM) is 6.1, why TM is valuable 6.2 and when TM is needed 6.3. Next various “Threat Modeling Approaches” 6.4 are described. Some of these limit the meaning of the word “threat” to intentional threats. This chapter concludes that for the purposes of database security testing a broad, operationally-oriented definition of the term “threat” is most helpful 6.5.

6.1 What is Theat Modeling?

TM is a powerful technique for performing application risk assessments as early as possible in the lifecycle [232, p 20], helping to assign appropriate resources to areas of greatest risk [232, p 17]. Good threat models do not automatically mean good software [232, p 20] but in order to build a secure system it is essential to understand threats [145, p 69]. Since it is impossible to predict all threats, threat management also needs a large detection and response component [289].

53 6.2 Why is Threat Modeling Valuable?

Cost-Eﬀective Testing Technique First and foremost TM is, in its own right, a powerful white-box static testing technique1. TM alone can uncover signiﬁcant security defects without any code being executed. Microsoft’s experience has been that TM at the design stage discovered about half of all software defects and that complex design bugs were not likely to be found in any other way [145, p 70]. Paraphrasing Weinberg, learning from the mistakes of others is the quickest, cheapest and most practical way to detect and prevent failures [363, 2.2.4].

Supports Risk Management This thesis generally supports the OWASP recommendation [232, p 20] to follow the NIST SP 800-3 Guide for Conducting Risk Assessments [310]. However other risk management standards are also relevant. ISO Guide 73:2009 [173, 2.1] provides widely accepted definitions of risk management [173, 2.1] vocabulary, which are referenced in other risk management standards including the enterprise risk management standards ISO 31000:2009 [172] and IEC 31010:2009 [171] and the IT security risk management standard ISO/IEC 27005:2011 [180]. Although ISO Guide 73:2009 does not define TM vocabulary, the abstract to ISO 31000:2009 states that enterprise risk management “can help organisations to increase the likelihood of achieving objectives, improve the identification of opportunities and threats and effectively allocate and use resources for risk treatment” [172, Abstract]. The TM approach recommended in this thesis is intended to support the end-to-end risk management process [173, 3.1], a summary of which is included in Appendix DIV.

Building a Business Case for Threat Modeling Shostack describes a number of approaches that can be used to build a business case for TM [334]. While researching TM, other possible ways of supporting a business case for TM were identiﬁed: Trusted external threat intelligence feeds, which are recommended by a number • of sources including NIST [310, Table D1], MITRE [14] and the Bank of England [256, 255];

Analysis of internal attack monitoring data e.g. aggregated analysis based on • appropriately placed Intrusion Detection System (IDS) sensors and Data Loss Prevention (DLP) systems;

Quantitative ﬁnancial modeling of cybersecurity threats [295]; and • Careful, preauthorised use of controversial vulnerability scanning search engines • such as the “Sentient Hyper-Optimized Data Access Network” (SHODAN) [333].

1The previous chapter5 intentionally omitted to highlight TM as an important security testing technique so that this point could be made with greater impact here. Any complete description of security testing should emphasise the importance of TM.

54 Picking up on this last point, without any intention of exploiting any organisation’s systems, I was able to use SHODAN to identify a large number of exposed databases on the Internet including databases belonging to large multi-national companies. To protect the security of the organisations involved, I am not disclosing any details of what I found or exactly how I used SHODAN. However vulnerabilties discovered using SHODAN that might allow attacks against internet-exposed databases included:

Open NETBIOS ports; • Disclosure of exact database software version numbers; • Meaningful error messages; • Reporting performance/timing statistics; • Use of SNMP; and • Use of HTTP Basic Authentication. • A quick demonstration of the ease with which potential attackers can ﬁnd externally exposed vulnerabilities, followed up by demonstrations in a controlled internal environment of how such vulnerabilities can be exploited, may help to build the business case for TM.

6.3 When are Threat Models needed?

Since security threats change frequently [232, p 7, 17] it is important to revisit the threat model as development progresses [232, p 20]. The earlier a good threat model is created, the more economic value it has. If threats are detected early and avoided then subsequent risk mitigation costs which would have been incurred, including testing costs, can be avoided. Threat models should be used to develop security requirements. They should also be used to develop security designs. Security threats identiﬁed at the design stage frequently involve violations of long-established security design principles [314]. Threat models should also be updated before and during security testing because attacker behaviour depends on controls [203] and each control added increases the attack surface [138]. Ideally threat models should be dynamically updatable so that tests based on threat models reﬂect the latest available threat information [136].

6.4 Threat Modeling Approaches

The following table provides a broad overview of various TM approaches. Note that a broad view has been taken of what is relevant. Some of the sources do not use the term “Threat Modeling” but are nevertheless concerned with analysis of threats. The Attackers column includes both analysis of attackers (identity/motivation/capability) and analysis of attack methods. The Design column includes retrospective analysis of vulnerabilities. The Impacts column includes both analysis of negative impacts of threats and analysis of the eﬀectiveness of defences against threats.

55 Table 6.1: Main Focus of Threat Modeliing approaches

Attackers Requirements Design Testing Operations Impacts Alexander [5] X Avizienis [13] X X Bodeau et al.[25, 24] X X X X CESG IS1 [46] X X X CMU/SEI [43, 42] X X X Common Criteria [174, X X X X 167, 168] DHS IT [259] X X X ENISA Threat Land- X scape [219] Fey & Kenyon [99] X X X Firesmith [101] X Hutchins et al. [148] X X X Intel TARA2 [307, 40] X X LINDUNN3 [81] X Landwehr [211] X Linde [213] X McDermott [226] X McDermott & Fox [227] X Microsoft STRIDE [145, X X X X 334] Microsoft DREAD [145, X 334] Myagmar [251] X MITRE CAPEC [241] X X MITRE TARA4 [374] X X NIST SP 800-30 [310] X X OCTAVE [3] X X OWASP [110] X X X Myagmar [251] X Ruck[312] X X X Schneier [321] X X Sindre [338] X Thomas (Branching Ac- X tivity Model) [349] van Lamsweerde [355] X

2Intel uses the acronym TARA for its “Threat Agent Risk Assessment” approach which analyses intentional and unintentional threats from human threat agents but does not model catastrophic events or technical failures [307] 3Deng’s PhD thesis [81] proposes a methodology for deﬁning privacy requirements which, in addition to considering certain system failures, uses the term “misactor” to describe “someone who intentionally or unintentionally initiates the misuse case”. 4MITRE uses the acronym TARA for its “Threat Assessment & Remediation Analysis” [374] approach which assesses the adequacy of operational controls against identiﬁed threats.

56 Common Ground The majority of TM approaches include:

architecture analysis focusing on data assets, data ﬂows and controls5; • graphical presentation formats6, supported by supplementary text, to promote • stakeholder involvement in construction and validation of threat models; and

ways of grouping similar items (threats, assets, vulnerabilities, controls etc) to • simplify analysis.

Generic threat groupings are included in [46, 307, 259, 40, 43, 42, 310]. Approaches to grouping of assets (structurally and/or functionally) are included in most frameworks, except those focusing exclusively on attackers or impacts. Approaches to grouping of assets by architecture tier are included in [259, 310]. For reasons explained below at 6.4, the TM approach proposed (using zones and levels) combines logical asset grouping concepts from [46, 145, 334] with architecture levelling concepts from [259, 310]. Shostack makes the astute observation that the most important objects identiﬁed by threat models are “Stepping Stones” [334] i.e. vulnerable targets which might allow attackers to build an attack chain.

Discussion of Diﬀerences Scope

TM approaches focusing on attackers and operations have a broader and more organi- sationally oriented scope. TM approaches focusing on requirements, design and testing tend to have a much narrower and more technically oriented scope. This thesis takes the position that for security testing of modern database systems, a comprehensive threat model covering both organisational and technical threats is needed. There appears to be no recent literature which oﬀers a comprehensive threat model for database systems [Finding 4].

Lifecycle

Some TM approaches focus on a particular point in the lifecycle. Operational approaches are biased towards top-down analysis. Vulnerability analysis approaches tend to take a bottom-up approach. However in the last chapter 5.4 it was established that security testing should start early in the lifecycle and be repeated. The special problems associated with database security testing were also identiﬁed 5.7. Therefore this thesis takes the position that for the purposes of database security testing, a comprehensive operationally-oriented TM approach is needed.

5Including the logical equivalents of security zone boundaries 6Threat model diagrams are generally considered simpler for stakeholders to understand and validate than textual descriptions of threats.

57 Relationship between Threats and Mitigations

Some requirements-centric approaches use threats to determine controls but thereafter do not model threats targeting the chosen controls. For reasons given by [334], supported by the references described at 6.3, it is important to consider the interplay between Threats, Requirements and Mitigations:

Figure 6.1: Threats, Requirements, Mitigations Interplay per [334, p 219 ﬁg 12.1]

The need to model vulnerabilities of countermeasures is clearly recognised under the CC scheme/ISO 15408 as the following ﬁgure demonstrates:

58 Figure 6.2: Vulnerabilities of Countermeasures per [26, p 20 ﬁg 4] which cites ISO 15408 [174].

Unintentional Threats A significant difference in usage of the term threat is whether or not unintentional causes such as catastrophic events, technical failures and human errors are included or excluded. Schneier recommends [322] a viewpoint paper by Johnston [199], writing on the subject of physical security, which argues strongly for a definition of threats that excludes unintentional causes and vulnerabilities. The same paper also argues that it is inappropriate to test against a threat assessment or vulnerability assessment [199]. This thesis agrees with [46, 259, 43, 42, 310] that the term threat should include all causes, both intentional and unintentional. A limitation of Microsoft’s STRIDE approach [145] is that it does not adequately model unintentional threats.

Analysis of Threat Sources Several of the TM approaches considered include a generic taxonomy of threat sources and qualitative scales to assess attributes of threat sources including capability/sophistication and intention/motivation [46, 307, 40, 43, 42]. For compatibility with other elements of the proposed framework (including references out to the OWASP testing guide [232]) and for ease of reference, this thesis takes as a starting point for a comprehensive view of threat sources the reference list provided by NIST SP800-30 [310][Decision 7].

Threat Modeling Tools This thesis focuses on TM principles. TM tools were not a major focus. However it is worth highlighting that few approaches are tool supported. Free to use tools are available from CESG [47] which supports TM at organisation/zone level and from Microsoft [236] which supports TM at system/software level. Microsoft’s tool supports a diagram

59 construction while CESG’s tool uses data entry forms to update a Microsoft Access format database ﬁle [47]. Some references can still be found to the tool-supported CCTA (Central Computer and Telecommunications Agency) Risk Analysis and Management Method (CRAMM) [282, 376, 294] but the software does not appear to be currently marketed or supported. However there appears to be no currently-supported TM tool which spans organisational and technical levels of threat modelings [Finding 5].

Levels of Threat Modeling NIST SP 800-30 Revision 1 Guide for Conducting Risk Assessments, which is aligned with the NIST SP 800-39 approach to organisational risk management [311], provides a clear position on the required granularity of risk assessments (and associated threat models) [310] as follows: Tier 1 - organisation level • Tier 2 - mission/business process level • Tier 3 - information system level • This thesis recommends a diﬀerent approach to threat model leveling [Decision 8] as follows: Tier 1 - organisation level • Tier 2 - zone level • Tier 3 - database level • Tier 4 - product level • The three main diﬀerences are that: 1. at Tier 2 security zones (which may contain several information systems) are preferred over business processes;

2. at Tier 3 the focus is on databases over information systems (which may sit above the database at Tier 2);

3. Tier 4 has been added to allow for separate assessment of threats to databases from lower level architecture components. The rationale for using different architecture tiers is to make it simpler to build clear threat models and to control the scope of related security testing. Focusing on security zones emphasises differences in threat levels and security control robustness. The TM c approach proposed is similar to the Domain-based Security (DBSy Copyright QinetiQ [294]) methodology upon which the Focus of Interest grouping of information assets in CESG IS1 [46] is based. Since business processes may span multiple security zones, using business processes to decompose the organisational architecture does not provide the same degree of clarity about differences in threat levels and control robustness. Since

60 information systems involve security dependencies between architecture tiers, it is clearer to separate out architecture tiers than to rely on a single tier for information systems. Also splitting out these layers simpliﬁes decision making about what has been tested and what has not been tested and to what level their security has been tested. If two zones have been tested to the same level then the risks of connecting them are much lower than if one of the zones has not been tested, or has been tested to withstand lesser threats.

6.5 Summary

This chapter has described what TM is 6.1, why TM is valuable 6.2 and when TM is needed 6.3. Diﬀerent TM approaches 6.4 have been reviewed. Combining this chapter’s review of threat modeling with the earlier discussion 2.3 that testing may be required to mitigate legal liabilities [30], this thesis supports a comprehenisve deﬁnition of threats that need to be modeled including:

adverse events (catastrophes, attacks, failure modes); • causes of adverse events (people, capability, motivation, attack diﬃculty, negli- • gence, process failures etc);

targets of intentional attacks (assets, exposures, attack surfaces, control weak- • nesses, vulnerabilities);

methods of attack (channels, attack chains, compromise methods etc); and • impacts of adverse events (losses, delays, penalties, opportunity costs, legal and/or • regulatory consequences, reputational damage etc.).

This chapter marks the end of Part I “Enterprise Context”. The next chapter7 explores the topic of “Database Security Management”.

61 62 Part II

Database Security Testing

”Where is the information? Lost in data. Where is the data? Lost in the #%&database” Joe Celko (b. 1947) 7 Database Security Management Review

Chapter Overview

Relationship to Goals As signposted earlier in the chapter1 “Introduction” table 1.1 and table 1.4 and in the previous chapter6, this chapter explores questions relating to the third goal “ To understand the diversity of database security requirements and solutions”. This chapter focuses speciﬁcally on answering the following questions:

What does database security management involve? • What database services are required? • What database services are available? How reliable are they? • What needs to be done to assure delivery of the required services? • What are the best practices for authorising and monitoring access to databases? • What falls outside the scope of database security management? • Precis of Chapter Contents This chapter brieﬂy explains what database security management is 7.1 before describing the core services which databases provide 7.2. The next section describes database service management 7.3 which leads into an explanation of the limits of database security management 7.4. The chapter summary 7.5 leads into the next chapter8 which explores technical diﬀerences between a diverse sample of database solutions.

7.1 Overview of Database Security Management

An interesting history of databases is provided by [210, Ch 1]. Signiﬁcant pre-relational databases which are still in use by some organisations include IMS [220, 216, 103] and CODASYL [220, 270, 347]. The history of how the SQL standard developed from

65 CODASYL is interesting [324]. The first 30 years of Oracle makes a good light read [275]. Regardless of what technologies are being used, fundamentally database security management is about meeting strategic data security objectives which have been defined at an enterprise information governance level. Writing in 1976, Martin [220] provides the following summary which he described as “The Essence of Data-Base Security”. ‘‘A data base should be: PROTECTED • RECONSTRUCTABLE • AUDITABLE • TAMPERPROOF • Its users should be: IDENTIFIABLE • Their actions should be: AUTHORIZED • MONITORED’’ • [220] Although database security management is still concerned with these security properties, the increasingly distributed and diverse nature of database systems has made it more difficult to achieve all of them. Database security management challenges now also include: 1. Identity Management - in many software applications user identification is performed independently of the database. Sharing database connections improves performance and scalability. However it means that at the database tier it is impossible to differentiate the activities of one user from another unless specific provision has been made to propagate the user’s identity in the content of every query received by the database. 2. Incomplete Audit Trail - if users are not identified at the database tier then database auditing and monitoring can only be achieved by correlating database events with events external to the database. 3. Data governance, ownership & stewardship - particularly when related data exists in multiple systems, new management processes and roles are needed to coordinate changes and enforce appropriate controls [357, 209, 340]. 4. Category management - the different security characteristics of database technologies and how they are being used, for example Online Transaction Processing (OLTP) [54, 150] Extract/Transform/Load (ETL) tools [150], data warehousing [150], data mining and various forms of Online Analytical Processing (OLAP) [54, 157, 150] need to be recognised and appropriate controls put in place.

66 5. Patch management - regular patching provides important protection against cyber- threats [44, Top 2,3] but potentially invalidates previous testing and drives the need for automated regression test suites.

6. Service level management - often the greatest security threat is a loss of availability. If a key database is unavailable the ﬁnancial impacts may be considerable. Poor database performance can also have serious organisational impacts. Insuﬃcient agility (change responsiveness) is also a potential threat. An organisation’s ability to meet regulatory compliance obligations may depend on being able to meet deadlines.

These are by no means the only database security management challenges. What they serve to illustrate is that database security management is a much broader and more challenging ﬁeld than it was in the 1970’s.

7.2 Core Database Services

Content-Addressable Storage Functional Perspective

What distinguishes databases from operating system services and other application software is that they provide generic services for storing and retrieving data based on its content. All databases provide the functional equivalent of the following verbs:

CREATE i.e. insert a new item of data into the database • READ i.e. retrieve a previously stored item of data • Most, but not all databases, provide the functional equivalent of the following verbs:

UPDATE i.e. change a previously stored item of data into the database • DELETE i.e. actually erase, or at least make inaccessible, a previously stored item • of data

Many, but not all, databases provide the ability to deﬁne a SCHEMA which controls data structures. A high proportion of databases provide the ability to index and retrieve arbitrary sets of previously stored data using some form of query language. Many, but not all, databases have the ability to perform bulk data import and/or bulk data export operations. Some databases have the ability to query other data external sources and combine data from those sources with directly managed data.

Architectural Perspective

The architecture of most, but not all databases, is based around support for:

67 CONCURRENCY i.e. enabling multiple users simultaneous access. Castano et • al. 1994 [41] p.1 citing [354, 55, 75] describes as one of the basic features of a DBMS “its ability to manage transactions simultaneously on behalf of concurrent applications” resulting in each application having the view of a virtually dedicated database.

RECOVERY i.e. the ability to restore service with little or no loss of data in the • event of a hardware or network failure. [20].

In order to support concurrency and recovery, transaction management features are required. The characteristics of a transaction are described by the acronym ACID (Atomic, Consistent, Isolated, Durable) [20, 41].

Security Perspective Databases which support ACID transactions provide the following security services:

INTEGRITY - ACID transaction management and concurrency controls ensure • consistency of the database

AVAILABILITY - ACID transaction management and recovery features protect • database availability

Many, but not all, databases support:

AUTHENTICATION - requiring users to present credentials before being allowed • access

AUDITING - tracking user activity (only possible if users are required to authen- • ticate)

ACCESS CONTROL - supporting diﬀerent levels of access by diﬀerent users • ADMINISTRATION - restricting certain operations, including changes to access • control, to privileged administrator accounts.

Databases which support authentication, access control and administration allow databases to provide CONFIDENTIALITY services1. If databases do not support any of these features then conﬁdentiality services must be implemented independently of the database.

Database Sharing and Isolation Although for many years databases have been used to provide shared services to multiple applications, the extent to which each application has the view of a virtually dedicated database has always been a source of friction. Sharing resources has undoubted

1Although some databases, both relational and non-relational, now support Secure Sockets Layer (SSL)/Transport Layer Security(TLS) it is important to note that most traditional relational databases have not used encrypted communication protocols. The scope of conﬁdentiality services provided by databases has therefore generally been limited to enforcing security rules within the database itself.

68 economic beneﬁts but sharing which is not strictly necessary goes against the long- established “Least Common Mechanism” security design principle described in Saltzer and Schroeder’s famous paper [314]. In recent years a number of writers including Fowler and Sadalage [113] have made the distinction between databases which are being used as an “integration database” shared between multiple applications and the alternative model of a dedicated “application database”. This distinction between shared and dedicated databases lies at the heart of many of the security threats and controls which are explored in this thesis. Databases which are robustly segregated and partitioned are simpler to secure, yet databases with minimal segregation and partitioning are often needed to meet integration requirements. Any security controls which do not adequately support integration may themselves present a security threat, particularly to information availability.

7.3 Database Service Management

Data Management Good Practices The Data Management Association (DAMA) Guide to the Data Management Body of Knowledge (DM-BOK) [28] published in 2009 provides a number of useful insights into what, as recently as five years ago, was generally accepted as good practice for enterprise data management. The DAMA’s Data Security Management process does include a Data Security Administrator role [28]. It also includes Data Privacy Issues as an input, Identity Management Technologies as a tool and no less than nine security related outputs: Data Security Policies, Data Privacy and Confidentiality Standards, User Profiles, Passwords and Memberships, Data Security Permissions, Data Security Controls, Data Access Views, Document Classifications, Authentication and Access History and Data Security Audits [28]. Although database security audits are covered, database security testing and tester roles (including functional testing roles) are not specifically addressed. Also important information security architecture artefacts (e.g. metadata, information asset valuations, threat models, risk assessments, impact analyses) were not considered by DAMA to merit inclusion either as inputs or outputs to the Data Architecture Management process. The DM-BOK would appear to be due for a security review [Finding 6].

Service Management Good Practices

R As a result of the inﬂuence of IT Service Management frameworks such as ITIL [123] and ISO 20000 [178, 182, 183] I have observed that database administrators are rou- tinely expected to provide support services aligned with higher level service management objectives such as:

Change Management (including patch management) • Conﬁguration Management • Availability Management • 69 Figure 7.1: DAMA Data Security Management processes per [28, Fig 5]

70 Capacity Management • Performance Management • Access Management • Incident Management • Most database security policies are implemented using discretionary access control, usu- ally Role Based Access Control (RBAC). Discretionary access control models place sig- niﬁcant reliance on the security of the internal environment. If attacks on databases by outsiders are successful in either compromising the credentials of insiders’ accounts or the mechanisms by which delegation occurs between non-database authentication mechanisms and database authentication then the attacks may wrongly be attributed to insiders. Knowledge of potential weaknesses in discretionary access control may allow insiders who are intentionally involved in attacks to be able to repudiate responsibility. Standards and good practices for access control are provided by [316, 315, 155,8].

Database Service Validation and Testing

R As identifed earlier at 3.7 during the ITIL Service Transition phase, service validation and testing is required. However I have not been able to identify a reputable source of generic good practice guidance for database service validation and testing.

7.4 Limits of Database Security Management

Many information security risks fall outside what database security management can protect including:

protecting the wider environment in which the database system operates; • protecting information before it enters the database system 2; • preventing information from being copied at the end-points where it is presented3; • protecting information after it is copied from the database system4; and • protecting how credentials are used outside the organisation’s control e.g. if a • DBA uses a company database password for a personal account elsewhere.

Some of these risks still fall within the organisation’s control and, if they are within the organisation’s control, then responsibility for managing them should be clearly allocated. However threat modeling may identify potential security (and privacy) risks which cannot

2“upstream” from the database conﬁdentiality, integrity, availability and non-repudiation properties can all be threatened. 3No matter if the end-point has sophisticated security partitions and controls to prevent screenshots and copy and paste, if a camera is around the contents of a display can be copied. 4“downstream” from the database conﬁdentiality, integrity, availability and non-repudiation properties can all be threatened.

71 be fully managed internally. Threats which cannot be managed should be transferred (e.g. insured against) or formally accepted at a senior management level. They should not be the focus of security tests.

7.5 Summary

This chapter has described what database security management is 7.1 and identiﬁed the core services provided by databases 7.2. A range of security management challenges relating to database systems have been outlined 7.3 as have the limits of database security management 7.4 . The wide range of security threats, the diversity of database technologies and the limits on what aspects of security can be managed make it important for management to understand:

what the current and future business security requirements are; • how business data usage is changing; • how security enforcing functions have been allocated; • whether the security enforcing functions are suﬃciently robust to withstand known • and expected threats.

The next chapter8 “Database Security Technical Review” considers technical threats which also aﬀect the extent and nature of security testing required.

72 “The system of nature, of which man is a part, tends to be self-balancing, self-adjusting, self-cleansing. Not so with technology.” E.F. Schumacher, Small is Beautiful, 1973 8 Database Security Technical Review

Chapter Overview

Relationship to Goals

As signposted earlier in the chapter1 “Introduction” table 1.1 and table 1.4 and in the previous chapter7, this chapter continues to explore questions relating to the third goal “To understand the diversity of database security requirements and solutions”. This chapter focuses speciﬁcally on answering the following questions:

What technical security services do databases provide? • What are the security strengths and limitations of diﬀerent database • technologies?

What threats are databases exposed to? • How can diﬀerences in the security characteristics of databases be • accommodated in a common testing framework?

During the course of this chapter skeleton threat models are developed which, if fully developed for a particular scope, would act as inputs to the threat-based security testing framework which is described in the next chapter9.

Precis of Chapter Contents

This chapter starts with a high level review of “traditional” technical database security 8.1. Next recent trends in database technology are described, primarily from a functional rather than a security perspective, although some security properties are discussed 8.2. This leads into a summary of new database security features 8.3. The following section provides a few worked examples of speciﬁc threats 8.4. A general approach to aligning database threats with related tests is described, before the chapter summary 8.6.

73 8.1 Traditional Technical Database Security

A very thorough treatment of traditional database security theory and practice, including many important database security models which are not explored here, is provided by [41]. Other useful references include [119, ch 9], [346, 152, 16]. A very broad summary is that databases which support Structured Query Language (SQL) support database-level access controls using the Data Control Language (DCL) subset of SQL which includes the following commands:

GRANT • REVOKE • Access may be granted or revoked by user name or by group (role). These commands can be applied to a wide range of structured database objects including:

TABLE • VIEW • STORED PROCEDURE • Being able to grant or revoke access in the database at this level of granularity allows organisations to implement practical data security policies, based on principles such as segregation of duties and need to know. Many commercial and open source database products include security extensions to the SQL standard. A recent example is [235]. Generally whenever additional object types are supported, the ability to grant and revoke access is extended to cover these objects also, at least at a coarse-grained level. Some traditional databases support fine-grained (row-level) security including Oracle, using the Label Security option [276] and PostgreSQL using the veil add-on [250]. Fine- grained security allows security policies based on the content of individual fields, which in turn allows implementation of Multi-Level Security (MLS) and Mandatory Access Control (MAC). Further developmenet of PostgreSQL security is being partially funded by the EU Framework Project 7 (FP7) [372, 303]. Separate database guard products (effectively application firewalls and activity monitors for databases) which can be installed between database servers and application servers or users include Guardium [19] (which is now owned by IBM), the open source product GreenSQL [90] and Imperva [151].

8.2 Database Technology Trends

It is interesting to note that discussions about object-relational mapping issues and possible alternative databases including graph databases was being discussed at least as early as 1989 [78]. Although not security-focused, a recent high level summary of database technologies, old and new, is provided by [210]. Most recent development in database technology can be traced to Brewer’s conjecture [31] later formalised into a proof by Gilbert [117] that it is impossible for a web service simultaneously to provide three guarantees:

74 Consistency • Availability • Partition-tolerance • This has been come to be known as the CAP Theorem. The consistency concept in this theorem subsumes the database notions of both Atomic and Consistent [117, p 3 footnote 3]. Partition-tolerance is a distributed systems concept meaning that if nodes of a cluster temporarily cannot communicate with each other they can continue to service transaction requests which reach them if consistency is not required or refuse to process transaction requests if consistency is required. Building on this understanding and driven by performance, scalability and availability demands from the largest companies operating on the Internet, many new database technologies have been developed which oﬀer diﬀerent service guarantees.

Figure 8.1: NoSQL Data Models per [126, p 6 ﬁg 1].

Stonebraker, a respected database veteran has actively championed new database technologies [345, 344], supported by Fowler [113] and others [217]. A critique of these new technologies is provided by [245]. Helpful summary guides to these new technologies are provided by [137, 297, 224]. Important work on data modeling and standardising application programming interfaces to new databases has been done by [32, 33, 34, 36]. There are good reference books for several speciﬁc technologies including: Hadoop [366], Graph databases [305] and SAP’s in-memory database HANA [373]. Major database vendors have started to support these new technologies. Oracle has re-branded BerkeleyDB as Oracle NoSQL [116]. A detailed list of NoSQL databases is maintained by [96]. A list of XML databases from 2010 is available at [27].

8.3 New Database Security Limitations

The most useful summary of NoSQL and NewSQL database features, both in terms of manageability and security, is provided by [126]. Key security findings of [126, p 16-17, Table 3] include: Server-to-Server (cluster node-to-node) database traffic is generally not encrypted • 75 Client-to-Server database traffic is often not encrypted • Many Key-Value stores (e.g. BerkeleyDB, Voldemort and Riak) and some Graph • Databases (e.g. Neo4J, HypergraphDB) do not support authentication, access control or auditing

The finding about lack of server-to-server encryption is consistent with my own observa- tions back in 2012 about an In-Memory Data Grid (IMDG) product, now being promoted as a NoSQL solution, that was included in a 2011 list of such products [56]. A significant security weakness is that database node joining such grids are not reliably authenticated. This is a possible topic for future research 12. In the mean time, the implications for testing of node-to-node server traffic not being encrypted and of some databases not supporting basic security functionality like authentication, access control and auditing are clear. If the database is not providing this functionality, it must be provided by the environment in which the database is operated - probably involving both application server and infrastructure components. Testing the security of databases which lack security features effectively amounts to security testing the environment which protects them. This supports the case for the definition of internal security zones and for modeling threats to internal security zones as part of the process of modeling threats to databases and performing security tests of databases.

8.4 Worked Examples of Database Security Attacks

One Byte Availability Attack from a Keyboard I particularly like this example because about 15 years ago, long before I started specialising in security or testing, I used it (with prior permission) to bring down a large system that was being tested. It was effectively a white-box test because I had a fair idea of the overall system design and an informed hunch that it would work. Variations of it have worked for me many times since. However I have not seen it written about. That is probably because it seems so trivial as to be unworthy of mention. The attack involved entering a single byte into a text field of an early web-based application, American Standard Code for Information Interchange (ASCII) [332] code 4 which has the meaning “End of Transmission” [9] by holding down the ALT key on a Microsoft compatible keyboard [247, 257]. The application in question did not perform a range check on every character entered so this byte was included in a quoted text string which was sent to the underlying database and stored. Nothing happened immediately but a few minutes later a stored procedure which ran at regular intervals failed and caused the database to become unavailable. Later follow-up investigations showed that a range of other rogue single input characters could affect the system adversely. What is particularly appealing about this example is the assymmetry: one person with a little knowledge and no software tools can potentially defeat a complex and expensive system with a very small data payload. In terms of database security testing lessons to be learned, it is very important to model threats related to encoding of characters. There may be many layers of character encoding and decoding in modern applications involving ASCII, UTF-8, UTF-16 etc [91,

76 Ch 8]. Attackers are often expert at using multiple levels of encoding [91, Ch 8] and format string vulnerabilities [371]. Negative testing for character related weaknesses should ideally include:

Automated fuzzing of all inputs ﬁelds which gives much higher coverage than • manual testing;

Automated source code scanning; • Targeted manual code review based on threat models. • NoSQL Injection Lesson A simple tutorial is provided by [254, p 44] showing how an equivalent to the well-known SQL injection attack or 1=1 for MongoDB is

|| 1==1

Following this attack with a NULL byte or a comment starting

// or