Secure and Resilient Software 1st Edition Mark

S. Merkow pdf download

https://ebookgate.com/product/secure-and-resilient-software-1st-
edition-mark-s-merkow/

Get Instant Ebook Downloads – Browse at https://ebookgate.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Architecting Secure Software Systems 1st Edition Asoke K.

Talukder

https://ebookgate.com/product/architecting-secure-software-
systems-1st-edition-asoke-k-talukder/

ebookgate.com

Resilient Liberalism in Europe s Political Economy 1st

Edition Vivien A. Schmidt

https://ebookgate.com/product/resilient-liberalism-in-europe-s-
political-economy-1st-edition-vivien-a-schmidt/

ebookgate.com

Android Software Development A Collection of Practical

Projects 1st Edition Mark Wickham

https://ebookgate.com/product/android-software-development-a-
collection-of-practical-projects-1st-edition-mark-wickham/

ebookgate.com

Engineering Secure Devices Dominik Merli

https://ebookgate.com/product/engineering-secure-devices-dominik-
merli/

ebookgate.com
Adaptive Dynamic and Resilient Systems 1st Edition
Niranjan Suri

https://ebookgate.com/product/adaptive-dynamic-and-resilient-
systems-1st-edition-niranjan-suri/

ebookgate.com

Strong Borders Secure Nation Cooperation and Conflict in

China s Territorial Disputes M. Taylor Fravel

https://ebookgate.com/product/strong-borders-secure-nation-
cooperation-and-conflict-in-china-s-territorial-disputes-m-taylor-
fravel/
ebookgate.com

Cisco Secure Intrusion Detection System 1st Edition Earl

Carter

https://ebookgate.com/product/cisco-secure-intrusion-detection-
system-1st-edition-earl-carter/

ebookgate.com

The Resilient Clinician 1st Edition Robert J. Wicks

https://ebookgate.com/product/the-resilient-clinician-1st-edition-
robert-j-wicks/

ebookgate.com

Google Compute Engine Managing Secure and Scalable Cloud

Computing 1st Edition Marc Cohen

https://ebookgate.com/product/google-compute-engine-managing-secure-
and-scalable-cloud-computing-1st-edition-marc-cohen/

ebookgate.com
 Information Technology / Programming Languages

Raghavan
Merkow
Developing more secure and resilient software has to be an integral part of the design and
the implementation of an application and not an afterthought. … This book pulls together the
state of the art in thinking about this important issue in a holistic way with several examples. It
takes you through the entire lifecycle from conception to implementation and highlights where
methodologies like the Microsoft Security Development Lifecycle can play a significant role in
improving the security and reliability of your software.
—Doug Cavit, Chief Security Strategist, Microsoft Corporation

… provides the reader with the tools necessary to jump-start and mature security within

SECURE and RESILIENT SOFTWARE

the software development lifecycle (SDLC). The authors bridge the gap between theory and
practical application by providing valuable processes, checklists, frameworks, and examples.
… a must read for anyone participating in requirements gathering, quality assurance,
development, and/or application security testing processes.
—Jeff Weekes, Sr. Security Architect at Terra Verde Services

… full of useful insights and practical advice from two authors who have lived this process.
… a tactical application security roadmap that cuts through the noise and is immediately
applicable to your projects. … You’ll learn how security evolves from threats to security
requirements, through security services like OWASP ESAPI, into security architecture, and
then into security testing and analysis leveraging OWASP ASVS. Highly recommended … .
—Jeff Williams, Aspect Security CEO and Volunteer Chair of the OWASP Foundation

Secure and Resilient Software: Requirements, Test Cases, and Testing Methods provides
a comprehensive set of requirements for secure and resilient software development and
operation. It supplies documented test cases for those requirements as well as best practices
for testing nonfunctional requirements for improved information assurance. This resource-
rich book includes:
• Pre-developed nonfunctional requirements that can be reused for any software
development project
• Documented test cases that go along with the requirements and can be used
to develop a Test Plan for the software
• Testing methods that can be applied to the test cases provided
• A CD with all security requirements and test cases as well as MS Word versions
of the checklists, requirements, and test cases covered in the book

Offering ground-level, already-developed software nonfunctional requirements and

corresponding test cases and methods, this book will help to ensure that your software meets
its nonfunctional requirements for security and resilience. The accompanying CD filled
with helpful checklists and reusable documentation provides you with the tools needed to
integrate security into the requirements analysis, design, and testing phases of your software
development lifecycle.

K12954
ISBN: 978-1-4398-6621-4
90000
w w w. c rc p r e s s . c o m

9 781439 866214
www.auerbach-publications.com

K12954_cvr mech.indd 1 10/10/11 9:02 AM

 SECURE and
RESILIENT
SOFTWARE
Requirements, Test Cases,
and Testing Methods

K12954_FM.indd 1 10/11/11 2:00 PM

This page intentionally left blank
 SECURE and
RESILIENT
SOFTWARE
Requirements, Test Cases,
and Testing Methods

Mark S. Merkow and Lakshmikanth Raghavan

K12954_FM.indd 3 10/11/11 2:00 PM

CRC Press
Taylor & Francis Group
6000 Broken Sound Parkway NW, Suite 300
Boca Raton, FL 33487-2742

© 2012 by Taylor & Francis Group, LLC

CRC Press is an imprint of Taylor & Francis Group, an Informa business

No claim to original U.S. Government works

Version Date: 20111005

International Standard Book Number-13: 978-1-4398-6622-1 (eBook - PDF)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts
have been made to publish reliable data and information, but the author and publisher cannot assume
responsibility for the validity of all materials or the consequences of their use. The authors and publishers
have attempted to trace the copyright holders of all material reproduced in this publication and apologize to
copyright holders if permission to publish in this form has not been obtained. If any copyright material has
not been acknowledged please write and let us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmit-
ted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented,
including photocopying, microfilming, and recording, or in any information storage or retrieval system,
without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copyright.
com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood
Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and
registration for a variety of users. For organizations that have been granted a photocopy license by the CCC,
a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used
only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com

and the CRC Press Web site at

http://www.crcpress.com
MerkowTOC.fm Page v Sunday, August 14, 2011 11:17 AM

Contents

Preface xi
How This Book Is Organized xii

What’s On the CD? xv

About the Authors xvii

Acknowledgements xix
From Mark Merkow xvii
From Laksh Raghavan xviii

Chapter 1 Introduction 1
1.1 Secure and Resilient 1
1.2 Bad Design Choices Led to the Vulnerable
Internet We Know Today 2
1.3 HTTP Has Its Problems, Too 4
1.4 Design Errors Continue Haunting Us Today 6
1.5 Requirements & Design: The Keys to a Successful
Software Project 7
1.6 How Design Flaws Play Out 10
1.6.1 DNS Vulnerability 10
1.6.2 The London Stock Exchange 10
1.6.3 Medical Equipment 11
1.6.4 Airbus A380 12
1.7 Solutions Are In Sight! 12
1.8 Notes 13

v
MerkowTOC.fm Page vi Sunday, August 14, 2011 11:17 AM

vi Contents

Chapter 2 Nonfunctional Requirements (NFRs) in Context 15

2.1 System Quality Requirements Engineering
(SQUARE) 15
2.1.1 Agree on Definitions 16
2.1.2 Identify Assets and Security/Quality
Goals 17
2.1.3 Perform Risk Assessments 17
2.1.4 Elicit Security Requirements 18
2.1.5 Prioritize Requirements 20
2.2 Characteristics of Good Requirements 21
2.3 Summary 22
2.4 Notes 23

Chapter 3 Resilience and Quality Considerations for

Application Software and the Application
Runtime Environment 25
3.1 Relationships among Nonfunctional Requirements 26
3.2 Considerations for Developing NFRs for your
Applications and Runtime Environment 26
3.3 Checking Your Work 51
3.4 Summary 52
3.5 Notes 52

Chapter 4 Security Requirements for Application Software 55

4.1 Security Control Types 55
4.2 Think Like an Attacker 56
4.3 Detailed Security Requirements 57
4.4 Identification Requirements 57
4.5 Authentication Requirements 61
4.6 Authorization Requirements 71
4.7 Security Auditing Requirements 79
4.8 Confidentiality Requirements 85
4.9 Integrity Requirements 91
4.10 Availability Requirements 96
4.11 Nonrepudiation Requirements 97
4.12 Immunity Requirements 99
4.13 Survivability Requirements 102
4.14 Systems Maintenance Security Requirements 104
4.15 Privacy Requirements 110
4.16 Summary 134
4.17 References 135
MerkowTOC.fm Page vii Sunday, August 14, 2011 11:17 AM

Contents vii

Chapter 5 Security Services for the Application Operating

Environment 137
5.1 The Open Group Architecture Framework (TOGAF)138
5.2 Standardizing Tools for an Enterprise Architecture 139
5.3 Security Technical Reference Model (TRM) 140
5.3.1 Identification and Authentication 141
5.3.2 System Entry Control 141
5.3.3 Audit 142
5.3.4 Access Control 143
5.3.5 Nonrepudiation 143
5.3.6 Security Management 144
5.3.7 Trusted Recovery 144
5.3.8 Encryption 144
5.3.9 Trusted Communications 145
5.4 Summary 146
5.5 References 146

Chapter 6 Software Design Considerations for Security

and Resilience 147
6.1 Design Issues 147
6.2 Architecture and Design Considerations 150
6.3 Special Security Design Considerations for
Payment Applications on Mobile
Communications Devices 154
6.4 Designing for Integrity 155
6.5 Architecture and Design Review Checklist 156
6.6 Summary 165
6.7 References 165

Chapter 7 Best Practices for Converting Requirements to Secure

Software Designs 167
7.1 Secure Design Approach 167
7.2 Reusable Security APIs/Libraries 168
7.3 Security Frameworks 168
7.4 Establishing and Following Best Practices
for Design 169
7.5 Security Requirements 169
7.6 Security Recommendations 170
7.7 What’s an Attack Surface? 171
7.8 What Is Managed Code? 173
MerkowTOC.fm Page viii Sunday, August 14, 2011 11:17 AM

viii Contents

7.9 Understanding Business Requirements for

Security Design 175
7.10 Summary 176
7.11 References 176

Chapter 8 Security Test Cases 177

8.1 Standardized Testing Policy 177
8.2 Security Test Cases 178
8.2.1 Test Cases for Identification
Requirements 179
8.2.2 Test Cases for Authentication
Requirements 181
8.3 Test Cases for Authorization Requirements 189
8.3.1 Test Cases for Security Auditing
Requirements 195
8.3.2 Test Cases for Confidentiality
Requirements 199
8.3.3 Test Cases for Integrity Requirements 203
8.3.4 Test Cases for Availability Requirements 206
8.3.5 Test Cases for Nonrepudiation
Requirements 207
8.3.6 Test Cases for Immunity Requirements 209
8.3.7 Test Cases for Survivability
Requirements 210
8.3.8 Test Cases for Systems Maintenance
Security Requirements 212
8.4 Summary 215

Chapter 9 Testing Methods and Best Practices 217

9.1 Secure Testing Approach 217
9.2 OWASP’s Application Security Verification
Standard (ASVS) 217
9.2.1 Application Security Verification Levels 219
9.2.2 Level 1—Automated Verification 220
9.2.3 Level 2—Manual Verification 220
9.2.4 Level 3—Design Verification 221
9.2.5 Level 4—Internal Verification 222
9.2.6 Security Testing Methods 224
9.3 Manual Source Code Review 224
9.4 Automated Source Code Analysis 225
MerkowTOC.fm Page ix Sunday, August 14, 2011 11:17 AM

Contents ix

9.4.1
Automated Reviews Compared with
Manual Reviews 226
9.4.2 Automated Source Code Analysis
Tools—Deployment Strategy 226
9.4.3 IDE Integration for Developers 227
9.4.4 Build Integration for Governance 227
9.4.5 Automated Dynamic Analysis 228
9.4.6 Limitations of Automated Dynamic
Analysis Tools 229
9.4.7 Automated Dynamic Analysis
Tools—Deployment Strategy 229
9.4.8 Developer Testing 230
9.4.9 Centralized Quality Assurance Testing 230
9.5 Penetration (Pen) Testing 231
9.5.1 Gray Box Testing 232
9.6 Summary 232
9.7 References 232

Chapter 10 Connecting the Moving Parts 235

10.1 OpenSAMM 236
10.2 Security Requirements 238
10.2.1 Security Requirements: Level 1 239
10.2.2 Security Requirements: Level 2 241
10.2.3 Security Requirements: Level 3 242
10.3 Security Testing 243
10.3.1 Security Testing: Level 1 245
10.3.2 Security Testing: Level 2 246
10.3.3 Security Testing: Level 3 247
10.4 Wrap-Up 249
10.5 References 249

Index 251
This page intentionally left blank
Preface.fm Page xi Sunday, August 14, 2011 11:17 AM

Preface

Systems Analysis Paralysis has met its doom!

With the tools and techniques from this book, you’ll find it’s worth its
weight in gold! We’ve done the heavy lifting for you in compiling a compre-
hensive set of software requirements for security, resilience, and any of the
other “-ilities” you can dream up, freeing you to concentrate on improving
software and its development without being stuck in the quicksand of anal-
ysis and design delays.
As a companion to our book, Secure and Resilient Software Develop-
ment (CRC Press, 2010), we’ve focused the attention of this book on the
earliest phases of the software development lifecycle (SDLC), making
accessible to you useful and proven techniques that, when properly
applied, can only serve to produce high-quality and easy-to-maintain
applications that will make you the envy of your peers! Security and Resil-
ience Software Requirements, Test Cases, and Testing Methods gives you
ground-level, directly usable software nonfunctional requirements and cor-
responding test cases and methods for conducting those tests to help assure
your development team’s ability to quickly incorporate nonfunctional
requirements into system specifications and assure that those requirements
will show up in developed systems.
Because catching errors when they are introduced can save you a up to
a hundred times the cost that would be incurred if the flaw migrated into
the final application, this book is intended to help you trap those errors
before they become flaws and eliminate them for good. Improving the
SDLC itself is as much a goal and outcome as improving the applications
that it produces, and you have in your hands everything you need to specify
good programs, make sure they’re developed with goodness intact, and test
cases and test methods to ensure that little if anything gets past the layers of
a defensive SDLC.

xi
Preface.fm Page xii Sunday, August 14, 2011 11:17 AM

xii Preface

Security and Resilience Software Requirements, Test Cases, and Testing

Methods was written with the following people in mind:

 Application/applet developers
 Software designers
 Web application systems analysts
 Software support personnel
 Payment card industry payment application (PA) standard and
data security standard (DSS) auditors
 Security architects
 Enterprise architects
 Application development department managers
 IT security professionals and consultants
 Project managers
 Application software security professionals
 Instructors and trainers for secure application development tech-
niques and practices

How This Book Is Organized

Chapter 1 opens the book with a contextual understanding of what secure
and resilient applications are, and discusses design flaws that lead to serious
vulnerabilities and consequences and the ways that defects increase the costs
of software maintenance and support.
Chapter 2 reviews the characteristics of high-quality software, expands
on the concepts of nonfunctional requirements, and introduces the System
Quality Requirements Engineering (SQUARE) Methodology from Carn-
egie-Mellon University. Chapter 3 begins peeling the onion of nonfunc-
tional requirements and their considerations as they relate to the quality of
applications and its runtime environment.
Chapter 4, the heart of the book, describes 93 software assurance func-
tional requirements for you to use in your own specifications, relieving you
of the painstaking effort of defining and documenting these requirements
from scratch.
Chapter 5 moves into describing how security is implemented as series
of policy-enforcing services that applications should use through standard-
ized APIs. Chapter 6 moves into the design phase of the SDLC by provid-
ing comprehensive recommendations and considerations for converting
requirements into positive steps that help to ensure that software is
designed securely, developed securely, and operated securely. Chapter 7
Preface.fm Page xiii Sunday, August 14, 2011 11:17 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing xiii

then goes into the next level of detail for converting requirements into
application design choices.
Chapter 8 moves into the testing phase of the SDLC by providing you
test cases that are related to the security requirements we provided in Chap-
ter 4. These test cases are intended for you to use when developing a testing
plan, which is then used for comprehensive testing of both the application’s
functional requirements and its security requirements.
Chapter 9 offers you some tools and best practices for testing applica-
tion software for assurance that security features are present and working as
intended in candidate release applications. It provides an inside look at the
OWASP Application Security Verification Standard (ASVS) for normalizing
the range of coverage and level of rigor for performing Web application
security verification. Chapter 10 then wraps up the book with a framework
and roadmap to help you implement what you learned in Chapters 1
through 9.
For updates to this book and ongoing activities of interest to the secure
and resilient software community, please visit www.srsdlc.com.
This page intentionally left blank
Preface.fm Page xv Sunday, August 14, 2011 11:17 AM

What’s On the CD?

The enclosed CD contains electronic versions of several of the documents

and templates referenced in Secure and Resilient Software: Requirements,
Test Cases, and Testing Methods

On the CD you will find:

 93 security requirements from Chapter 4 as MS Word files
 73 test Cases from Chapter 8 as MS Word files for testing the
requirements selected
 Checklists from Chapters 3 and 6

Requirements
In the RequirementTemplates folder on the CD you will find the 93
requirements organized by the security topics they reference. Each require-
ment family has its own directory and within each directory are separate MS
Word template files along with a Directory file that contains the require-
ment file name and its description:

 Identification Requirements – Folder IDEN

 Authentication Requirements – Folder ATEN
 Authorization Requirements – Folder AUTR
 Security Auditing Requirements – Folder AUDT
 Confidentiality Requirements – Folder CONF
 Integrity Requirements – Folder INTG
 Availability Requirements – Folder AVAL
 Non-repudiation Requirements – Folder NREP
 Immunity Requirements – Folder IMMU
 Survivability Requirements – Folder SURV
 Systems Maintenance Requirements – Folder SYSM
 Privacy Requirements – Folder PRIV
xv
Preface.fm Page xvi Sunday, August 14, 2011 11:17 AM

xvi What’s On the CD?

You can use these requirements in any number of ways:

 Export them in any file format that MS Word supports into your
Requirements Management System
 Copy and update them for your Business Requirements Document
(BRD), Master Requirements Document (MRD, or whatever you
use to specify system functional and nonfunctional requirements)

Test Cases
In the TestCasesTemplates folder on the CD you will find the 73 test cases
and a directory for them. Each test case supports one of more security
requirements from Chapter 4.

Using the Test Cases

You can use the test case templates to create your customized testing plans
for your software based on the techniques described in Chapter 10. These
test cases can be combined and integrated into your own test plan docu-
ment and imported into your testing platform (if it is supported).

Checklists
In the Checklists folder on the CD you will find electronic versions of:

 Table 3.3 Requirements Gathering Phase Completion Checklist

 Table 6.4 MSDN Architecture and Design Review Checklist
Preface.fm Page xvii Sunday, August 14, 2011 11:17 AM

About the Authors

Mark S. Merkow, CISSP, CISM, CSSLP works at PayPal Inc. (an eBay
company) in Scottsdale, Arizona, as Manager of Information Security Poli-
cies, Standards, Training, and Awareness in the Information Risk Manage-
ment area. Mark has more than 35 years of experience in information
technology in a variety of roles, including applications development, sys-
tems analysis and design, security engineering, and security management.
Mark holds a masters degree in decision and info systems from Arizona
State University (ASU), a masters of education in distance learning from
ASU, and an undergraduate degree in computer info systems from ASU. In
addition to his day job, Mark engages in a number of other extracurricular
activities, including consulting, course development, online course delivery,
and writing columns and books on information technology and informa-
tion security.
Mark has authored or coauthored ten books on IT and is a contribut-
ing editor on four others.
Mark remains very active within the information security commu-
nity, working in a variety of roles for the Financial Services Information
Sharing and Analysis Center (FS-ISAC), the Financial Services Technol-
ogy Consortium (FSTC), and the Financial Services Sector Coordinating
Council (FSCCC) on Homeland Security and Critical Infrastructure Pro-
tection. He is the chairman of the Education Committee for the FS-ISAC
and is a founding member of the Research and Development Committee
of the FSSCC.
Lakshmikanth Raghavan, CISM, CRISC (Laksh) works at PayPal Inc. (an
eBay company) as Staff Information Security Engineer in the Information
Risk Management area, specializing in application security. Laksh has more
than ten years of experience in the areas of information security and infor-
mation risk management, and has provided consulting services to Fortune
500 companies and financial services companies around the world.

xvii
Preface.fm Page xviii Sunday, August 14, 2011 11:17 AM

xviii About the Authors

Laksh holds a bachelor’s degree in electronics and telecommunication

engineering from the University of Madras, India. He enjoys writing secu-
rity-related articles and has spoken on the various dimensions of software
security at industry forums and security conferences.
This is Laksh’s second book.
Preface.fm Page xix Sunday, August 14, 2011 11:17 AM

Acknowledgements

From Mark Merkow

To start, I’m thankful to my friend and co-author, Laksh Raghavan, who
apparently was born with the mission to improve the state of software qual-
ity and the skill to share his depth of knowledge and expertise with the rest
of the planet!
Thanks to my wife, Amy, and to my family for the ongoing support
and encouragement in my writing another book.
The following people deserve appreciation beyond measure for their
help, support, expertise, encouragement, and reassurance, which make the
process of writing far easier than it otherwise is: Gus Anagnos, Denise
Anderson, Mark Ardis, Robert Auger, Warren Axelrod, Michael Barrett,
Doug Cavit, John Carlson, Joseph Cavanaugh, Don Cochran, Cindy
Donaldson, Jeff Edelen, Chris Faciana, Beth Hubbard, Ajoy Kumar, Wally
Lake, James Landis, Doug Maughan, Nancy Mead, Bill Nelson, Jim Palmer,
Brian Peretti, David Rice, Robert Rodriguez, Jim Routh, Dan Schutzer,
Paul Smocer, Andy Steingruebl, Nicole Stuchlik, Roger Thornton, Jeff
Weekes, Angela Weinman, Errol Weiss, Jeff Williams and Leigh Williams.
Tremendous thanks goes to Theron Shreve, John Wyzalek, and the
entire staff at Derryfield Publishing Services and Taylor and Francis for their
commitment to excellence, efficiency, humor, and drive that makes working
with them a total pleasure!
Special thanks goes to my agent, Carole McClendon, and the crew at
Waterside Productions.

xix
Preface.fm Page xx Sunday, August 14, 2011 11:17 AM

xx Acknowledgements

From Laksh Raghavan

First up, I’m truly indebted to my mentor and coauthor, Mark Merkow, for
providing me one more opportunity to be part of a book project. But for his
timely, invaluable inputs and continuous guidance, this book wouldn’t have
been possible.
Thanks to my wife, Janani, for her encouragement and continued sup-
port for another book project. Heartfelt thanks to my parents and my fam-
ily for their overwhelming encouragement.
A million thanks and deepest gratitude to the following people who
have enlightened me with their expertise and encouraged me with their
warm words: Gus Anagnos, Robert Auger, Warren Axelrod, Michael Bar-
rett, Bhaskar Bhattacharya, Joseph Cavanaugh, Bil Corry, Avinandan Datta,
Jeff Edelen, Kevin Glass, Ryan Gurney, Sanjeev Harit, Jeff Hodges,
Madhukar I.B., Ashish Kumar, Santhosh Kumar, Wally Lake, James Landis,
Upendra Mardikar, Rick Marvin, Brett McDowell, Debarshi Mukherjee,
Chandar N, Rohit Nand, Jim Palmer, Pierre Pellissier, Sneha Phadke, Rob-
ert Raja, Ram Ramdattan, Srini Rangaraj, Srikar Sagi, Arun Selvarajan,
Kurihara Shinji, Adam Shostack, Nittono Shuuji, Andy Steingruebl, Pira-
manayagam T, Alex Tosheff, Murali V, David Weisman, Jeff Williams and
Nam Wu.
Special thanks to John Wyzalek, Theron Shreve and the entire produc-
tion crew at Derryfield Publishing Services and Taylor and Francis for their
professional support & guidance in getting this book done.
Tremendous thanks to my agent, Carole McClendon, and the crew at
Waterside Productions—for always getting stuff done at warp speed!
Chap1.fm Page 1 Sunday, July 31, 2011 10:41 AM

Chapter 1

Introduction

Economic costs of faulty software in the United States range in the tens of
billions of dollars every year and represent about one percent of the U.S.
gross domestic product (GDP).1
And things are getting worse.
In efforts to “do something” about the problem, we’ve gone from ignor-
ing it, to acknowledging its existence, and lately to testing for vulnerabilities
that we’re certain we’ll find. Rather than trying to test-in quality, would it
not be better to build it in from the start?
Secure and resilient application software can only emerge from a soft-
ware development lifecycle (SDLC) that treats nonfunctional requirements
(NFRs) and quality requirements as a core element of every phase, as well as in
postdeployment. By mandating security and resilience within the SDLC
itself and ensuring that requirements related to security and resilience are
treated as equal citizens with all functional requirements, managers can rest
better at night knowing their infrastructure and applications are continu-
ously working as their defender rather than their enemy.
In our book entitled Secure and Resilient Software Development,2 we
advocated an environment in which software security and resilience
require a holistic, comprehensive approach. The primary goal of this book
is to help people understand that when NFRs are neglected at program
specification time, they will not magically appear when the application
undergoes testing.
Failing to specify any desirable quality features up front is a surefire recipe
for guaranteeing their absence!

1.1 Secure and Resilient

In Secure and Resilient Software Development, we defined software resilience as:

1
Chap1.fm Page 2 Sunday, July 31, 2011 10:41 AM

2 Introduction

. . . the ability to reduce the magnitude and/or duration of disruptive

events. The effectiveness of a resilient application or infrastructure soft-
ware depends on its ability to anticipate, absorb, adapt to, and/or
recover rapidly from a potentially disruptive event.
(Secure and Resilient Software Development, Chapter 1, p. 2)

Resilient and secure code is neither cheap nor easy to attain, but unless
it’s thoroughly considered from the start of a development project till the
very end, it’s completely unattainable. Bolting on security to an insecurely
developed application will not make it secure or resilient—it will only make
it more complicated to understand, maintain, and operate.
Testing for security features and testing for security bugs in the later
phases of the SDLC while ignoring security and resilience NFRs in all ear-
lier SDLC phases will not produce a secure and resilient application. Just as
quality cannot be tested in to products, high-quality application develop-
ment requires stringent attention from the very start.
A common recurring theme in software development shops is the diffi-
culty in specifying what’s needed at the start of a development effort for
security and resilience. This book is intended to help reduce this difficulty
and help systems analysts, designers, and would-be users of the application
to document these NFRs by reusing and customizing what we offer here.

1.2 Bad Design Choices Led to the Vulnerable

Internet We Know Today
In a presentation entitled “Internet Nails,” Marcus Ranum presents3 a
detailed recap of small, yet bad, design choices made by well-meaning engi-
neers long ago that resulted in significant downstream problems with the
technologies that run the Internet today.
One example is the file transfer protocol (FTP), which was developed
around 1971. FTP was used to transfer files from one computer to another
during the early ARPANET days, long before the commercial Internet came
into being. A few years later, another protocol called “host-to-host protocol”
was developed, then later renamed as network control protocol (NCP).
NCP was then reimplemented and rewritten by software engineers as the
transmission control protocol (TCP)—the underlying technology that runs
the Internet today.
To understand the issues of TCP requires an understanding of network
sockets. In simple terms, network sockets are abstract rendezvous points for
Chap1.fm Page 3 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 3

two systems to use for communicating over the Internet. All connections on
the Internet happen using network sockets in a simple four-step process:

1. A server listens for traffic on particular socket port.

2. A client connects to that port on the server.
3. The client transmits its data.
4. Once the data transmission is complete, the client disconnects.

With FTP, it’s a little more complicated. Figure 1.1 and the list below
show the steps required for using the FTP protocol:

1. The FTP server listens on particular network socket port.

2. A client connects to that port on the server and transmits USER
login command to the server.
3. The server responds with a request for the “Password”.
4. The client sends the user’s password to the server.
5. When the client requests a file it creates and listens to a port cho-
sen at random and sends a message back to the server instructing
it to “transfer the file to the port that it just created and on which
it is actively listening.”
6. The server then connects back to the client on that port and trans-
mits the file.
7. The client then drops the connection to the server with a “Bye”.

Take a look at steps 5 and 6 in the list. Does it seem odd to you that the
protocol specifies having the client open the port and having the server con-
nect back to it? When the host-to-host protocol was written, data could
only be transmitted in one direction over a socket, and the same was true
with NCP. Once TCP/IP was developed, this problem was solved and data
could travel in both directions on a socket, but FTP was never rewritten to
take advantage of that feature.
FTP continued to work the way it always did, and no one thought to
redesign it. So why does this matter in the long run?
The unexpected effect was that FTP inadvertently created the need for
a firewall! In the early days of TCP/IP, existing router technologies could not
Chap1.fm Page 4 Sunday, July 31, 2011 10:41 AM

4 Introduction

Figure 1.1 A Simplified FTP Sequence Diagram

handle the odd “callback” behavior of FTP (steps 7 and 8) because corpora-
tions wanted to control and prevent random people the outside from con-
necting back into their networks.
Engineers, including Marcus Ranum, began developing firewall sys-
tems. In 1991, Ranum sold his first firewall for $195,000. This firewall
industry grew into a $100 million industry by 1997; by 2009, network edge
defense technology (with firewalls that added more and more functions like
spam filtering) was estimated to be a billion-dollar industry!
In hindsight, it would have taken a couple of hours for a good pro-
grammer to fix FTP back in 1975. Since then, the industry has spent mil-
lions of dollars on this problem, and making it worse still—FTP remains in
use with the same problems!

1.3 HTTP Has Its Problems, Too

Let’s now take a look at some of the design choices made on the hypertext
transfer protocol (HTTP) and the downstream consequences that we con-
tinue dealing with today.
Chap1.fm Page 5 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 5

In the early 1990s, the Internet implementation was largely dominated

by the Berkeley System Distribution (BSD) UNIX operating system and its
derivatives. The TCP/IP stack across all these UNIX versions used the same
codebase. In that TCP/IP implementation, there was a concept of incoming
connection limit. The protocol specifies a partial socket table and a system
socket table. Since the programmers of the stack had very little program and
system memory (~1 MB) to use, they made a choice to have twelve entries
for the partial socket table and 2048 entries for the system socket table.
Whenever a new incoming connection was initiated, one of the twelve
entries in the partial table would be filled. TCP is a stateful protocol and
requires a three-way handshake to fully set it up. Until such time that the
handshake completes, the entry is queued up in the partial table. Once the
connection is fully set up, the entry is removed and moved to the system
socket table.
After a time, some of these UNIX systems began crashing when thir-
teen partial connections were made to them—the OS didn’t know how to
deal with more than twelve, as the protocol stack had a limitation of just
twelve.
Around 1995, Sir Tim Berners-Lee developed the World Wide Web
(WWW), and because of this overloaded socket problem, he decided to
make HTTP stateless—meaning there would be no continuity between
request and response pairs. A Web page might trigger five, ten, or even fif-
teen different connections, depending on the contents of the page and the
browser would then assemble all of these objects into a single formatted
web page.
Making such separate requests one-by-one (serially) would cause a page
to load very slowly. In response, browser programmers implemented some
performance hacks—they loaded all of those images and objects in four or
five parallel connections, rather than serially. Servers then were handed a
hard problem of dealing with five parallel connections instead of just one
from a single client.
To fix this problem, by 1996, the UNIX server programmers changed
their code so that the server could handle tens of thousands of incoming
connections at a time.
In 1997, after Internet commerce took off, people noticed that HTTP,
being a stateless protocol, was not so great after all, for various reasons:

 Security: A developer had to encrypt all the confidential data

between the server and client, and all keys negotiated for the
Chap1.fm Page 6 Sunday, July 31, 2011 10:41 AM

6 Introduction

encryption had to be discarded after that stateless connection was

closed, which is computationally expensive.
 Shopping carts: When a user added an item to their shopping cart
and navigated away from that page for other items, the cart would
be empty.
 Logging in and tracking: There were issues with Web site logins
and with keeping track of what a user does on a site once they’re
logged in.

To solve this problem, a separate session management scheme had to be

implemented. Cookies were designed and developed to enable servers to
maintain the state of a Web session. Several problems showed up right away:

 Software frameworks such as PHP, .NET, AJAX, Ruby, and others

each had to support new models to reintroduce state management
in the form of session management. Each of those frameworks did
this in their own way, and programmers had to learn what each
technology required for correct implementation.
 Load balancers had to be put in front of Web server farms to track
state for each Web connection
 New vulnerabilities, like session hijacking, cross-site scripting,
SQL injection attacks, and others were made possible because of
these new implementations.

1.4 Design Errors Continue Haunting Us Today

Today we still are dealing with some bad design choices that were made ear-
lier. Eric Butler, a freelance Web application developer, released4 FireSheep.
This Firefox browser plug-in lets anyone on an open wireless network sniff
out (copy) other users’ cookies that are intended for sites that only use SSL
for the login process but not for the rest of the session (Hotmail is a good
example of this). When logging into a Web site, you begin by submitting
your username and password. The server then checks to see if an account
matching this information exists and, if it does, replies back to your browser
with a cookie used by your browser for all subsequent requests to that site.
It’s extremely common for Web sites to protect your password by encrypting
the initial login, but very uncommon for them to encrypt all other traffic.
This leaves the cookie and the user it belongs to vulnerable. On an open
wireless network, cookies are basically broadcast through the air, making
these attacks extremely easy to pull off.
Chap1.fm Page 7 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 7

Looking back, the fundamental problem that led to the “stateless”

design choice for HTTP was already fixed by 1996, before the World Wide
Web and e-commerce became mainstream—but nobody went back and
redesigned HTTP . . .
In their report 2010 Top Cyber Security Risks,,HP Digital Vaccine Labs
details a sharp rise in attacks in 2010 targeting Web applications. They
claim this is due to botnet-based attack toolkits that exploit known Web
application vulnerabilities to compromise user machines and company serv-
ers. “There’s a growing market of underground, mafia-type organizations
that develop and maintain toolkits for helping criminals compromise and
monetize victims . . . We’re seeing specialized scripts that you can load onto
a host after you’ve compromised it that will use the host to launch further
attacks, and that script may only be 100 Kbytes in length,” said Mike
Dausin, manager of advanced security intelligence for HP DVLabs.5

1.5 Requirements & Design: The Keys to a Successful

Software Project
In an IEEE Spectrum Magazine article,6 Robert Charter explains some of the
common reasons software projects fail. The article covers a variety of pit-
falls, ranging from “unrealistic or unarticulated project goals” to “poor
project management,.” Two of the pernicious reasons actually lie within the
software development lifecycle itself:

 Badly defined system requirements

 Sloppy development practices

The article explains how critical requirements are within the SDLC.
Consider a purchasing system that automates the ordering, billing, and
shipping of parts. A salesperson can input a customer’s order, have it auto-
matically check the pricing and contract requirements, and arrange to have
the parts and invoice sent to the customer from the warehouse.
The requirements for the system specify four basic steps.

1. The sales process creates a bill of sale.

2. The bill of sale is sent through a legal review process for the contrac-
tual terms and conditions of the potential sale and approves them.
3. The provisioning process sends out the parts purchased.
4. The finance process sends out an invoice.
Chap1.fm Page 8 Sunday, July 31, 2011 10:41 AM

8 Introduction

Without clear requirements for Step 1, programmers may treat every

order as though it was placed in the company’s main location, even though
the company has branches in several states and countries. That single mis-
take, in turn, affects how tax is calculated, what kind of contract is issued,
what shipping rates are used, and so on.
The sooner the error is detected and corrected, the better. Think about
knitting a sweater. If you spot a missed stitch right after you make it, you
can simply unravel a bit of yarn, correct the mistake, and move on. But if
you don’t catch the mistake until the end, you may need to ravel all the way
back to that stitch just to redo it.
If the software development team fails to catch their omission until
final system testing—or worse, after the system has been rolled out—the
costs to correct the error are many times greater than if they’d caught the
mistake while they were still working on the initial sales process program.
Unlike a missed stitch in a sweater, the problem is far harder to pin-
point—the programmers only see that errors are appearing, but do not
know which of several causes might be in play. Even after the original error
is corrected, the programmers will need to change all other calculations and
documentation and then retest every step.
From the earliest days of software development, studies have shown
that the cost of remediating vulnerabilities or flaws in design are far lower
when they’re caught and fixed during the early requirements/design phases
than after launching the software into production.
Figure 1.2 shows the phases of the SDLC in which defects are intro-
duced; seventy percent of them are introduced in the Requirements and
Design phases. However, detecting the majority of those defects does not
happen until the user acceptance testing phase or after the application goes
into production.
Barry Boehm blames7 late inspection for software errors as the cause of
an increase of up to one hundred times the cost that would have been
required if the errors were caught sooner in the SDLC, as illustrated in Fig-
ure 1.3. If a defect is found in the earlier SDLC phases, costs to remove it or
prevent it are minimal. If the defect is not found until after the software is
launched and placed in maintenance mode, the cost to remediate it is one
hundred times more.8
Therefore, the earlier you can integrate security processes into the
development life cycle, the cheaper software development becomes over the
long haul.
Chap1.fm Page 9 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 9

Figure 1.2 SDLC Phases in Which Defects Are Introduced

Figure 1.3 Costs of Fixing Errors by Phase

Chap1.fm Page 10 Sunday, July 31, 2011 10:41 AM

10 Introduction

1.6 How Design Flaws Play Out

Following are some examples of what can happen when design flaws make
their way into production systems, devices, and products that are intended
for the public’s use.

1.6.1 DNS Vulnerability

In early 2008, Dan Kaminsky discovered a critical vulnerability in the

domain name service (DNS) system. The DNS system translates domain
names that people understand, like www.blah.com, to IP addresses that
computers understand, like 204.11.200.1. This creates an entire family of
vulnerabilities—for example, the DNS system on PCs can be fooled into
thinking that the IP address for www.badsite.com is really the IP address for
www.goodsite.com, and there’s no way for users to tell the difference. This
flaw allows the criminals at www.badsite.com to trick you into doing all
sorts of things when your browser takes you to their site, like giving up your
bank account details. Kaminsky had discovered a particularly nasty variant
of this DNS cache-poisoning attack.
What’s important is how good design decisions can make software secure
and resilient from vulnerabilities and attacks yet to come. Years ago, cryp-
tographer Daniel J. Bernstein looked at DNS security and decided that
source port randomization was a smart design choice. Bernstein didn’t know
about Kaminsky’s attack, but he saw a general class of attacks and realized
that this enhancement could protect against them. Consequently, the DNS
program he wrote in 2000, “djbdns”, did not need to be patched—it was
already immune to Kaminsky’s attack. That’s what a good design looks like.
It’s not just secure against known attacks; it’s also secure against unknown
attacks and attacks yet to come.

1.6.2 The London Stock Exchange

Back in 1986, the London Stock Exchange decided9 to automate its system
for settling stock transactions. Seven years later, after spending $600 mil-
lion, it scrapped the Taurus system’s development, not only because the
design was excessively complex and cumbersome, but also because the man-
agement of the project was, in the words of one of its own senior managers,
“delusional.” As investigations revealed, no one wanted to know the true
status of the project, even as problems stacked up, deadlines were missed,
and costs soared.
Chap1.fm Page 11 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 11

1.6.3 Medical Equipment

Medical equipment is not immune to bad software either. In a series of acci-

dents, therapy planning software created by Multidata Systems Interna-
tional, a U.S. firm, miscalculated10 the proper dosage of radiation for
patients undergoing radiation therapy. Multidata’s software allowed a radia-
tion therapist to draw on a computer screen the placement of metal shields
called “blocks” designed to protect healthy tissue from the radiation.
However, the software only allowed technicians to use four shielding
blocks. Doctors in Panama wanted to use five! The doctors discovered that
they could trick the software by drawing all five blocks as a single large
block with a hole in the middle. What the doctors did not realize is that the
Multidata software computed different answers in the configuration
depending on how the hole was drawn—draw it in one direction and the
correct dose is calculated, draw it in another direction and the software rec-
ommends twice the necessary exposure of radiation.
A subsequent International Atomic Energy Agency (IAEA) report
stated11 that there were several characteristics of the computerized treatment
planning system that made it relatively easy for the error to occur. These
were:

1. Differing ways of digitizing blocks were accepted by the com-

puter treatment planning system.
2. There was no warning on the computer screen when blocks were
digitized in an unacceptable way (i.e., any way that was different
from the one prescribed in the manual).
3. When blocks were digitized incorrectly, the treatment planning
system still produced a diagram that was the same as those pro-
duced when the data was entered correctly, thereby giving the
impression that the calculated results were correct.

At least eight patients died, while another twenty received overdoses

likely to cause significant health problems. The Panamanian physicians,
who were legally required to double-check the computer’s calculations by
hand, were indicted for murder.
Chap1.fm Page 12 Sunday, July 31, 2011 10:41 AM

12 Introduction

1.6.4 Airbus A380

The Airbus A380, the largest passenger airliner in the world, was also bitten
by bad software. In a Pan-European project12 to build the world’s biggest
passenger plane, you might expect the language barriers between manage-
ment and engineers, but you’d hope the computers at least would speak the
same language.
In the spring of 2005, however, just as the Airbus A380 was taking
shape in hangars outside Toulouse, France, engineers came across a huge
software issue that reportedly cost the company $6 billion by delaying the
first flight by two years.
The French production facility had been using the latest version of the
industry standard computer-aided design (CAD) software, CATIA 5, for its
CAD designs. The Germans, on the other hand, had worked in CATIA 4,
which handles 3D objects differently.
When they tried to match up their halves of the plane, it was like trying
to weld the front of a Chevrolet Camaro to the back of a Cadillac Escalade.
The biggest problem was that the wiring plans were completely incompati-
ble. Subtle differences in the software meant mismatched connections
needed rerouting to connect the two disparate halves of the plane.
Even when developers wrote code to translate between the two ver-
sions, complications remained, with engineers pointing out that there was
insufficient space to carry power cables far enough away from signal wires to
prevent interference.
If you’re wiring one plug, a couple of late changes to a wiring diagram
isn’t a major issue, but with the A380’s 530 km of cabling, more than
100,000 individual wires, and 40,000 connectors, a single change has a neg-
ative cascading effect.
The list of problems could go on and on to fill all the pages of this
book. But, what we’re looking for are solutions that every software designer,
developer, architect, and tester can use to make their own software secure
and resilient.

1.7 Solutions Are In Sight!

Software security is one of those legacy problems that will not be solved
overnight. It requires a substantial investment in the right tools and pro-
cesses, active diligence, ongoing awareness and evangelism, continuing edu-
cation, and determination to make any headway.
Chap1.fm Page 13 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 13

Organizations need a set of well-defined, reusable requirements for

security and resilience in order to bootstrap secure software development
efforts. Developing a set of security requirements is a fundamental founda-
tional step in the SDLC. Testers need those requirements to build their test
cases. With no documented requirements, there would be no test cases and
no assurance whatsoever that NFRs would make it into software that the
public will use—and letting malicious users become your security testers is a
great strategy for failure, or worse!
Organizations that develop software also need robust sets of test cases
and testing methods to ensure that those requirements have been properly
implemented in the software being developed.
In upcoming chapters we’ll provide exhaustive detailed requirements,
test cases, and testing methods to help you make sure that you’re incorporat-
ing the right kind of nonfunctional requirements in the right place and the
right time for all your software development projects.

1.8 Notes
1. “The Economic Impacts of Inadequate Infrastructure for Soft-
ware Testing,” National Institute of Standards & Technology,
accessed March 10, 2011, www.nist.gov/director/planning/
upload/report02-3.pdf.
2. Mark S. Merkow & Lakshmikanth Raghavan, Secure and Resil-
ient Software Development (CRC Press, 2010).
3. “TEDxMidAtlantic: Marcus Ranum,” YouTube, accessed
December 19, 2010, www.youtube.com/
watch?v=o59mQhBiUo4.
4. “Firesheep,” codebutler [blog], accessed November 17, 2010,
http://codebutler.com/firesheep.
5. “Web Applications See Sharp Rise In Attacks,” Information Week,
accessed April 12, 2011, www.informationweek.com/news/secu-
rity/vulnerabilities/ showArticle.jhtml?arti-
cleID=229400808&cid=RSSfeed_IWK_News,
and
“Reducing Risk through Requirements-Driven Quality Manage-
ment: An End-to-End Approach,” HP Software Customer Con-
nection, accessed April 11, 2011, http://
viewer.media.bitpipe.com/1000733242_857/1181846419_126/
74536mg.pdf.
Chap1.fm Page 14 Sunday, July 31, 2011 10:41 AM

14 Introduction

6. “Why Software Fails,” IEEE Spectrum: Technology, Engineering,

and Science News, accessed December 18, 2010, http://spec-
trum.ieee.org/computing/software/why-software-fails/0.
7. Barry W. Boehm and Richard Turner, Balancing Agility and Disci-
pline: A Guide for the Perplexed (Boston, MA: Addison-Wesley,
2006).
8. Barry W. Boehm and V. Basili, “Software Defect Reduction Top
10 List,” IEEE Computer (IEEE Computer Society, Vol. 34, No.
1, January 2001.)
9. “Why Software Fails,” IEEE Spectrum: Technology, Engineering,
and Science News, accessed December 18, 2010http://spec-
trum.ieee.org/computing/software/why-software-fails/4.
10. “History's Worst Software Bugs,” Wired, accessed December 19,
2010, www.wired.com/software/coolapps/news/2005/11/
69355?currentPage=all.
11. “NRC Information Notice 2001-08, Supplement 2: Update On
Radiation Therapy Overexposures In Panama,” Massachusetts
Insitute of Technology, accessed December 19, 2010, http://
web.mit.edu/6.033/www/papers/theratron.pdf.
12. “When Computers Go Wrong,” PC Pro, accessed December 19,
2010, www.pcpro.co.uk/features/363580/when-computers-go-
wrong/5.
Chap2.fm Page 15 Sunday, July 31, 2011 10:41 AM

Chapter 2

Nonfunctional
Requirements (NFRs) in
Context
Throughout this book, we have bound security and resilience together
because, in many cases, when you’re using a defensive software development
methodology to meet security objectives, resilience tags along for the ride.
Examples include improved reliability, rapid recoverability, and simplified
portability. Other NFRs require deliberate attention and relate to both the
application itself and the environment under which your applications run.
Keep in mind the following working definition of nonfunctional
requirements as you proceed through the book:

NFR: A software requirement that describes not what the software will
do but how the software will do it-for example, software performance
requirements, software external interface requirements, software design
constraints, and software quality attributes.1

In Chapter 2, you will learn about the model for System Quality
Requirements Engineering (SQUARE) as well as what constitutes a good
requirement description.

2.1 System Quality Requirements Engineering (SQUARE)

System Quality Requirements Engineering (SQUARE) is a process model
developed2 at Carnegie Mellon University (CMU). SQUARE provides a
means for eliciting, categorizing, and prioritizing security requirements for
information technology systems and applications. The focus of the model is
to build security and quality concepts into the early stages of the development
life cycle. The model can also be used for documenting and analyzing the
security and quality aspects of a development project.

15
Chap2.fm Page 16 Sunday, July 31, 2011 10:41 AM

16 Nonfunctional Requirements (NFRs) in Context

The nine different steps of SQUARE are:

1. Agree on definitions
2. Identify security goals
3. Develop artifacts to support security requirements definition
4. Assess risks
5. Select elicitation technique(s)
6. Elicit security requirements
7. Categorize requirements
8. Prioritize requirements
9. Inspect requirements

SQUARE usually requires about three months of effort to complete.

CMU also developed a shorter version, called SQUARE-Lite, with these five
steps:

1. Agree on definitions
2. Identify assets and security goals
3. Perform risk assessment
4. Elicit security requirements
5. Prioritize requirements

SQUARE-Lite can be used by organizations that already have a require-

ments engineering process in place and want to fit security and quality
requirements into it, or by organizations that have not yet decided to imple-
ment the full SQUARE process model but still want some of the benefits.
Let’s look at these five steps in detail.

2.1.1 Agree on Definitions

Agreement is the initial step that the requirements engineering team and
stakeholders undergo. They must first agree on a common set of terminology
and definitions. The process is carried out through a set of interviews and
guarantees effective and clear communication throughout the requirements
Chap2.fm Page 17 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 17

engineering process. This involves using public resources, such as the Soft-
ware Engineering Body of Knowledge (SWEBOK) [IEEE 05], the IEEE
610.12 Standard Glossary of Software Engineering Terminology [IEEE 90],
and Wikipedia.
Agreement also resolves ambiguity and differences in perspective. The
exit criteria for this step are a documented set of definitions. Typical exam-
ples are access control (ACL), antivirus software, artifacts, assets, control,
attacks, audit information, authentication, availability, back doors,
breaches, brute force, buffer overflow, cache cramming, cache poisoning,
confidentiality, nonrepudiation, denial-of-service (DoS), intrusion, mal-
ware, and so on.

2.1.2 Identify Assets and Security/Quality Goals

Identifying assets that need protection in the system and their correspond-
ing security and quality goals is the next objective. Initially, different stake-
holders will have different security and quality goals. Development teams
need to formally agree on a set of prioritized security goals for the project.
Without overall security goals for the project, it is impossible to identify the
priority and relevance of any security and quality requirements that are gen-
erated. The quality goals of the project must be in clear support of the
project’s overall business goal, which also must be identified and enumer-
ated in this step.
Once the goals of the various stakeholders are identified, they must be
reviewed, prioritized, and documented. In the absence of consensus, an
executive decision may be needed to prioritize the goals.
The exit criteria for this step is to document a single business goal for the
project and several prioritized security and quality goals for the overall soft-
ware system.

2.1.3 Perform Risk Assessments

This step begins with identification of the vulnerabilities and threats that
face the system, the likelihood that the threats will materialize as real
attacks, and any potential consequences of an attack. Without a risk assess-
ment, organizations may be tempted to implement security requirements or
countermeasures without any logical rationale.
Once the threats have been identified by the risk assessment method,
they must be classified according to their likelihood. These will aid in prior-
itizing the security requirements generated at a later stage. For each threat
Chap2.fm Page 18 Sunday, July 31, 2011 10:41 AM

18 Nonfunctional Requirements (NFRs) in Context

identified, a corresponding security requirement can identify a quantifiable

and verifiable response. For instance, a requirement may describe speed of
containment, cost of recovery, or limit to the damage that can be done to
the system’s functionality.
The requirements engineering team should facilitate the completion of
a structured risk assessment, which is often performed by an external risk
expert. Once complete, review the results of the risk assessment and share
them with stakeholders.
The exit criteria for this step are documented threats, their likelihoods,
and their classifications.

2.1.4 Elicit Security Requirements

Prior to this step, the requirements engineering team must select an elicita-
tion technique that is suitable for the client organization and project. Multi-
ple techniques may work for the same project. The difficulty with selecting
a technique is choosing one that can adapt to the number and expertise of
the stakeholders, the size and scope of the client project, and the expertise of
the requirements engineering team.
CMU has done an extensive evaluation and analysis of the different
types of elicitation methods and has shown that the Accelerated Require-
ments Method (ARM) has been successful for eliciting security require-
ments. The evaluation criteria include:

 Adaptability: The method can be used to generate requirements in

multiple environments. For example, the elicitation method works
equally as well with a software product that is near completion as
with a project in the planning stages.
 Computer-aided software engineering (CASE) tool: The method
includes a CASE tool. (The Software Engineering Institute defines
a CASE tool as “a computer-based product aimed at supporting
one or more software engineering activities within a software
development process.”)
 Stakeholder acceptance: The stakeholders are likely to agree to the
elicitation method in analyzing their requirements. For example,
the method isn’t too invasive in a business environment.
 Easy implementation: The elicitation method isn’t overly complex
and can be properly executed easily.
 Graphical output: The method produces readily understandable
visual artifacts.
Chap2.fm Page 19 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 19

 Quick implementation: The requirements engineers and stakehold-

ers can fully execute the elicitation method in a reasonable length
of time.
 Shallow learning curve: The requirements engineers and stakehold-
ers can fully comprehend the elicitation method within a reason-
able length of time.
 High maturity: The elicitation method has experienced consider-
able exposure and analysis in the requirements engineering com-
munity.
 Scalability: The method can be used to elicit the requirements of
projects of different sizes, from enterprise-level systems to small-
scale applications.3

Though results will vary from one organization to another, CMU’s

approach is worth considering as a choice for your organization.
The Security Elicitation step is the heart of the SQUARE process. This
step describes the execution of the elicitation technique that was previously
selected.

Avoiding Potential Mistakes

The biggest mistake that the requirements engineering team can make in
this step is to elicit nonverifiable, vague, or ambiguous requirements. Each
requirement must be stated in a manner that will enable relatively easy veri-
fication once the project has been implemented. For instance, the require-
ment “the system shall improve the availability of the existing customer
service center” is impossible to measure objectively. Instead, the require-
ments engineering team should encourage the production of requirements
that are clearly verifiable and, where appropriate, quantifiable. A better ver-
sion of the previously stated requirement would thus be “The system shall
handle at least 300 simultaneous connections to the customer service cen-
ter.” Later in this chapter, you’ll learn what makes for a good write-up of
nonfunctional requirements, and throughout the book you’ll see hundreds
of good examples.
A second mistake that the requirements engineering team can make in
this step is to elicit implementations or architectural constraints instead of
requirements. Requirements are concerned with what the system should do,
not how it should be done.
Chap2.fm Page 20 Sunday, July 31, 2011 10:41 AM

20 Nonfunctional Requirements (NFRs) in Context

Face-to-Face Elicitation Works Best

A key success factor is face-to-face interaction with all stakeholders. The exit
Criteria is an initial set of documented nonfunctional requirements for the
system.
Different methodologies dictate differing documentation techniques
for requirements gathering and analysis. Fans of the Unified Modeling Lan-
guage and Rational Unified Process are very familiar with the documenta-
tion tool called use cases to capture functional requirements, but you may
find that they are not well-suited for capturing NFRs. You might find that
misuse cases to describe the steps of performing a malicious act against a sys-
tem are useful, just as you might describe an act that the system is supposed
to perform in a use case. Here are some suggested steps to follow:

1. Begin with a preexisting knowledge base of common security

problems for systems that are similar to the one under develop-
ment, and determine whether an attacker may have cause to
think such vulnerability is possible in the system being devel-
oped. Then, try to describe how the attacker would leverage the
problem. if it exists.
2. Brainstorm on the basis of a list of system resources. For each
resource, attempt to construct misuse cases in connection with
each of the basic security services: authentication, confidentiality,
access control, integrity, and availability.
3. Third, brainstorm on the basis of a set of existing use cases. This
may be useful for identifying representative risks and for ensuring
that the first two approaches did not overlook any obvious
threats. Misuse cases derived in this fashion are often written in
terms of a valid use and then annotated to have malicious steps.4

2.1.5 Prioritize Requirements

In most cases, the development team will be unable to implement all of the
nonfunctional requirements due to the lack of time and/or resources, or
due to changes in the goals of the project. The purpose, then, of this step in
the SQUARE process is to prioritize the nonfunctional requirements, so
that the stakeholders can choose which requirements to implement and in
which order.
During prioritization, some of the requirements may be deemed
entirely infeasible to implement. In such cases, the requirements engineer-
Chap2.fm Page 21 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 21

ing team has a choice; completely dismiss the requirement from further
consideration, or document the requirement as “future work” and remove it
from the draft set of project requirements. This decision should be made
after consulting with all the stakeholders and after leadership approvals.

2.2 Characteristics of Good Requirements

As you’re collecting and documenting NFRs to include in analysis and
design documentation, it’s not important that every category of NFR has at
least one or more specific requirement—requirements are not generally
organized by which NFRs they meet. What is important is that your analy-
sis is thorough and that all aspects of software quality are considered. What’s
also important is that these requirements be documented to meet the crite-
ria of a “good” requirement statement. Table 2.1 lists some of the attributes
for good requirements and may be used to help refine them as you docu-
ment them.

Table 2.1 Characteristics of Good Requirements

Characteristic Explanation
Cohesive The requirement addresses one and only one thing.
Complete The requirement is fully stated in one place with no miss-
ing information.
Consistent The requirement does not contradict any other require-
ment and is fully consistent with all authoritative external
documentation.
Correct The requirement meets all or part of a business or resil-
ience need as authoritatively stated by stakeholders.
Current The requirement has not been made obsolete by the pas-
sage of time.
Externally The requirement specifies a characteristic of the product
Observable that is externally observable or experienced by the user.
Feasible The requirement can be implemented within the con-
straints of the project.
Chap2.fm Page 22 Sunday, July 31, 2011 10:41 AM

22 Nonfunctional Requirements (NFRs) in Context

Table 2.1 Characteristics of Good Requirements (continued)

Characteristic Explanation
Unambiguous The requirement is stated concisely, without unnecessary
technical jargon, acronyms, or other esoteric terms or
concepts. The requirement statement expresses objective
fact, not subjective opinion. It is subject to one and only
one interpretation. Vague subjects, adjectives, preposi-
tions, verbs, and subjective phrases are avoided. Nega-
tive statements and compound statements are not used.
Mandatory The requirement represents a stakeholder-defined char-
acteristic or constraint.
Verifiable Implementation of the requirement can be determined
through one of four possible methods: inspection, analy-
sis, demonstration, or test. If testing is the method needed
for verifiability, the documentation should contain a sec-
tion on how a tester might go about testing for it and
what results would be considered passing.

Source: Wapedia Wiki: Requirements, http://wapedia.mobi/en/Requirements.

Another approach to ensuring that NFRs meet the characteristics of

goodness uses the SMART mnemonic for their development:

 Specific—Is it without ambiguity, using consistent terminology,

simple, and at the appropriate level of detail?
 Measurable—Can you verify that this requirement has been met?
What tests must be performed, or what criteria must be met, to
verify that the requirement is met?
 Attainable—Is it technically feasible? What is your professional
judgment of the technical “do-ability” of the requirement?
 Realistic—Do you have the right resources? Is the right staff avail-
able? Do they have the right skills? Do you have enough time?
 Traceable—Is it linked from its conception through its specifica-
tion to its subsequent design, implementation, and test? 5

2.3 Summary
There’s no question that deriving nonfunctional requirements in software
development projects can be a daunting and enormous task that requires
dozens of labor-hours from a cross-section of people who have a stake in the
Chap2.fm Page 23 Sunday, July 31, 2011 10:41 AM

Secure and Resilient Software: Requirements, Test Cases, and Testing 23

road, where maintenance, support, and operational costs quickly negate any
benefits the software was planned to provide.
In Chapter 2 you learned about CMU’s SQUARE methodology for
deriving NFR and what constitutes well-developed and well-written NFRs.
In Chapter 3, we’ll begin to peel the onion, first looking at resilience
and software quality categories of NFRs and cover requirements related to
the application software and the operating environment. Chapter 4 then
digs into security NFRs for applications and Chapter 5 into security infra-
structure services for the operating environment.

2.4 Notes
1. John Mylopoulos, Lawrence Chung, Brian A. Nixon, and Eric
Yu. Non-functional requirements in software engineering, Univer-
sity of Texas Dallas. accessed February 22,2011, www.utdal-
las.edu/~chung/BOOK/book.html.
2. “SQUARE Instructional Materials,” Software Engineering Insti-
tute, accessed February 22, 2011, www.cert.org/sse/square/
square-description.html.
3. “Requirements Elicitation Case Studies Using IBIS, JAD, and
ARM,” Build Security In, accessed February 23, 2011, https://
buildsecurityin.us-cert.gov/bsi/articles/best-practices/require-
ments/532-BSI.html.
4. “Detail Misuse Cases,” OWASP.org, accessed February 27, 2011,
www.owasp.org/index.php/Detail_misuse_cases.
5. “Architecture Resources for Enterprise Advantage.” Breedmeyer
Consulting Web site, accessed February 27, 2011,
www.ewita.com/newsletters/10023Files/NonFunctReq.PDF.
This page intentionally left blank
Other documents randomly have
different content
 The Act of the Lords of Councell at Edinburgh.
August 30, 1639, containing the Answer of the
preceding Supplication.

T
HE which day, in presence of the Lord Commissioner and the
Lords of Privie Councell, compeired personally John Earle of
Rothes; James Earle of Montrose; John Lord Lowdoun; Sir George
Stirling of Keir, Knight; Sir William Douglas of Cavers, Knight; Sir
Henry Wood of Bonytoun, Knight; John Smyth, Burgesse of
Edinburgh; Mr Robert Barclay, Provest of Irwing; Mr Alexander
Henderson, Minister at Edinburgh; and Mr Archbald Johnstoun, Clerk
to the Generall Assembly; and, in the name of the present sitting
Generall Assembly, gave in to the Lord Commissioner, and Lords of
Privie Councell, the Petition above written; Quhilk being red, heard,
and considerit be the said Lord Commissioner and Lords of Privie
Counsell, they have ordainit, and ordains the samen to be insert and
registrat in the books of Privie Counsell, and, according to the desyre
thereof, ordains the said Confession and Covenant to be subscrived
in tyme comeing, be all His Majesties Subjects of this Kingdome, of
what ranke and qualitie soever.

The Kings Majesties Commissioners Declarations.

T
he which day His Majesties Commissioner and Lords of Councell,
after the receiving of the Supplication of the Generall Assembly,
anent the subscribing of the Covenant, having returned to the
Assembly, His Majesties Commissioner, in name of the Councell,
declared: That he had received the Supplication of the Assembly,
desiring that the Covenant might receive the force of an Act of
Councell, to be subscribed by all his Majesties Subjects, that they
had found the desire so fair and reasonable, that they conceived
themselves bound in duety to grant the same, and thereupon have
made an Act of Councell to that effect, and that there rested now
the Act of Assembly; and that he himself was so fully satisfied, that
he came now, as his Majesty’s Commissioner, to consent fully unto
it; and that he was most willing that it should be enacted here in this
Assembly, to oblige all his Majesties Subjects to subscribe the said
Covenant, with the Assemblies explanation. And because there was
a third thing desired, His subscription, as the Kings Commissioner,
unto the Covenant, which he behooved to do, with a Declaration in
writ; and he declared, as a Subject, he should subscribe the
Covenant as strictly as any, with the Assemblies Declaration; but as
His Majesties Commissioner in his name he behoved to prefix to his
subscription the Declaration following, which no Scots Subjects
should subscribe or have the benefit of, no, not himself as Earle of
Traquair. The tenor whereof follows:—
Seeing this Assembly, according to the laudable forme and
custome heretofore kept in the like cases, have, in a humble and
dutiful way, supplicate to us His Majesties Commissioner, and the
Lords of His Majesties most honourable Privie Councell, That the
Covenant, with the explanation of this Assembly, might be
subscribed: And to that effect that all the subjects of this Kingdome,
by act of Councell, be required to doe the same: And that therein,
for vindicating themselves from all suspitions of disloyaltie or
derogating from the greatnesse and authoritie of our dread
Soveraigne, have therewith added a Clause, whereby this Covenant
is declared one in substance with that which was subscribed by His
Majesties Father of blessed memory, 1580, 1581, 1590, and oftner
since renewed. Therefore I, as His Majesties Commissioner, for the
full satisfaction of the Subjects, and for settling a perfect Peace in
Church and Kingdome, doe, according to my foresaids Declaration
and Subscription, subjoyned to the Act of this Assembly, of the date
the 17 of this instant, allow and consent that the Covenant be
subscribed throughout all this Kingdome. In witnes whereof I have
subscribed the premisses.

Likeas his Majesties Commissioner, read and gave in the Declaration

following, of his consent to the Act of the Assembly, 17 August,
 anent the causes of our by gone evils.

I,
John Earle of Traquair, His Majesties Commissioner in this present
Assembly, doe, in His Majesties Name, declare, that,
notwithstanding of His Majesties own inclination, and many other
grave and weightie considerations, yet such is His Majesties
incomparable goodnesse, that, for settling the present distractions,
and giving full satisfaction to the Subject, He doth allow, like as I,
His Majesties Commissioner, doe consent to the foresaid Act, and
have subscribed the premisses.

Likeas His Majesties Commissioner read and gave in the Declaration

following:—

I
T is alwayes hereby declared by me, His Majesties Commissioner,
That the practise of the premisses, prohibited within this Kirk and
Kingdome, outwith the Kingdome of Scotland, shall never bind nor
inferre censure against the practises outwith the Kingdome; which,
when the Commissioner required to be insert in the Register of the
Kirk, and the Moderator, in name of the Assembly, refused to give
warrant for such practise, as not agreeable with a good conscience,
His Grace urged that it should be recorded, at least that he made
such a Declaration, whatsoever was the Assemblies Judgement in
the contrair: And so it is to be understood to be insert here onely
vocitative.

Act ordaining the subscription of the Confession of Faith and

Covenant, with the Assemblies Declaration.

T
HE Generall Assembly, considering the great happinesse which
may flow from a full and perfect Union of this Kirk and Kingdome,
by joyning of all in one and the same Covenant with God, with the
Kings Majestie, and amongst our selves, having, by our great Oath,
declared the uprightnesse and loyaltie of our intentions in all our
proceedings, and having withall supplicated His Majesties high
Commissioner, and the Lords of His Majesties honorable Privie
Councell, to injoyn, by Act of Councell, all the Lieges in time coming
to subscribe the Confession of Faith and Covenant, which, as a
testimony of our fidelity to God and loyaltie to our King, we have
subscribed: And seeing His Majesties high Commissioner, and the
Lords of His Majesties honorable Privie Councell, have granted the
desire of our Supplication, ordaining, by civill authority, all His
Majesties Lieges, in time comming, to subscribe the foresaid
Covenant, that our Union may be the more full and perfect, We, by
our Act and Constitution Ecclesiasticall, doe approve the foresaid
Covenant in all the Heads and Clauses thereof, and ordaines of new,
under all Ecclesiasticall censure, that all the Masters of Universities,
Colledges, and Schooles, all Schollers at the passing of their
degrees, all persons suspect of Papistry, or any other errour, and,
finally, all the members of this Kirk & Kingdome, subscribe the same
with these words prefixed to their subscription: “The Article of this
Covenant, which was, at the first subscription, referred to the
determination of the Generall Assembly, being determined, and
thereby the five Articles of Perth; the government of the Kirk by
Bishops; the civill places and power of Kirkmen, upon the reasons
and grounds contained in the Acts of the Generall Assembly,
declared to be unlawfull within this Kirk: we subscribe according to
the determination foresaid.” And ordaines the Covenant, with this
Declaration, to be insert, in the Registers of the Assemblies of this
Kirk, Generall, Provinciall, and Presbyteriall, ad perpetuam rei
memoriam; and, in all humility, supplicates His Majesties high
Commissioner, and the honourable Estates of Parliament, by their
authoritie to ratifie and injoyne the same, under all civill paines,
which will tend to the glory of God, preservation of Religion, the
Kings Majesties honour, and perfect peace of this Kirk and
Kingdome.
 Aug. 30. 1639.
Act anent Appellations.

T
HE Assembly appointed, that, in all time hereafter, no
Appellations should be, leaping over either Presbyterie or Synod,
but to ascend by degrees as from the Kirk Session to the Presbytry,
or from the Presbyterie to the Synod, and from the Synod to the
Generall Assembly, except it be after the Synod be past, and
immediatly before the Generall Assembly, or in the time thereof, and
renewes all former Acts made to this effect.
 Act anent advising with Synods and Presbyteries
before determination in Novations.

T
HE Generall Assembly, considering that the intended Reformation
being recovered, may be established, Ordaines, that no Novation
which may disturb the peace of the Church, and make division, be
suddenly proponed and enacted: But so as the motion be first
communicate to the severall Synods, Presbyteries, and Kirks, that
the matter may be approved by all at home, and Commissioners
may come well prepared, unanimously to conclude a solide
deliberation upon these points in the Generall Assembly.
 Act anent Ministers Catechising, and Familie
Exercises.

T
HE Assembly, considering that the long-waited-for fruits of the
Gospel, so mercifully planted and preserved in this Land, and the
Reformation of our selves and Families, so solemnly vowed to God of
late in our Covenant, cannot take effect, except the knowledge and
worship of God be carried from the Pulpit to every family within each
Parish, hath therefore appointed, that every Minister, besides his
paines on the Lords day, shall have weekly catechising of some part
of the Paroch, and not altogether cast over the examination of the
people till a little before the Communion. Also, that in every Familie
the worship of God be erected, where it is not, both Morning and
Evening, and that the Children and Servants be catechised at home,
by the Masters of the Families, whereof accompt shall be taken by
the Minister, and Elders assisting him in the visitation of every
Family: And, lest they fail, that visitation of the severall Kirks be
seriously followed by every Presbyterie, for this end among others.
The execution and successe whereof, being tryed by the Synods, let
it be represented to the next Generall Assembly.
 Sess. XXIV. 30. Aug. à meridie.
The Assemblies Supplication to the Kings Majestie.
Most Gracious Soveraigne,

W
EE, Your Majesties most humble and loyall Subjects, the
Commissioners from all the parts of this your Majesties ancient
and native Kingdome, and members of the Nationall Assembly,
conveened at Edinburgh by your Majesties speciall indiction, and
honoured with the presence of Your Majesties High Commissioner,
have been waiting for a day of rejoycing, and of solemne
Thanksgiving to be rendred to God by this whole Kirk and Kingdome,
for giving us a King so just and religious, that it is not only lawfull for
us to be Christians under Your Majesties government, which
sometime hath been the greatest praise of great Princes, but also
that it hath pleased Your gracious Majestie to make known that it is
Your Royall will and pleasure, that all matters Ecclesiasticall be
determined in free Nationall Assemblies, and matters civill in
Parliaments; which is a most noble and ample expression of Your
Majesties justice, and we trust shall be a powerfull meane of our
common happinesse under your Majesties most blessed Raigne. In
the mean while we doe most humbly, upon the knees of our hearts,
blesse your Majestie for that happinesse already begun in the late
Assembly at Edinburgh, in the proceedings whereof, next under God,
we have laboured to approve our selves unto Your Majesties Vice-
gerent, as if Your Majesties eyes had been upon us, which was the
desire of our soules, and would have beene the matter of our full
rejoycing, and doe still continue Your Majesties most humble
supplicants for Your Majesties civill sanction and ratification of the
constitutions of the Assembly in Parliament: That your Majesties
Princely power, and the Ecclesiasticall Authority, joyning in one, the
mutual embracements of religion and justice, of truth and peace,
may be seene in this Land, which shall be to us as a resurrection
from the dead, and shall make us, being not only so farre recovered,
but also revived, to fill Heaven and Earth with our praises, and to
pray that King CHARLES may be more and more blessed, and His
throne established before the Lord for ever.

T
HE Assembly appoints the next Generall Assembly to sit at
Aberdeene the last Tuesday of July next, 1640 years. And
warneth all parties, Universities, and Burrows, to send their
Commissioners, for keeping the samine. And thereafter the Assembly
was concluded by giving of thanks by the Moderator, and singing of
a Psalme, according to the custome.
FINIS.
 Index of the Principall Acts of the Assembly at
Edinburgh, 1639. Not printed.161
1.—The Kings Majesties Commission to John Earle of Traquair.
2.—Election of Master David Dickson, Moderator.
3.—The Kings Majesties Commissioners and the Assemblies
Declarations anent the Assembly of Glasgow.
4.—Renunciation of Master Alexander Lindsay, pretended Bishop
of Dunkell, of Episcopacie.
5.—Commission for Visitation of the Universitie of S. Andrews.
6.—Commission for Visitation of the Universitie of Glasgow.
7.—Act reviving former Acts against going of Salt Pannes on the
Sabbath day.
8.—Act for drawing up of a Catechisme.
9.—Articles and Overtures to be presented to the ensuing
Parliament.
10.—The Report of the Committee appointed for Examination of
the Booke called “The Kings Manifesto or Declaration.”
11.—The Covenant, or Confession of Faith.
12.—Act anent the Adjoyning of some Kirks in the Ile of Boot to
the Presbyterie of Denune.
13.—Act Adjoyning some Kirks in the Iles of Coill and Tyrie to the
Provinciall of Kilmoire.
14.—Commission for Visitation of the Colledge of Aberdeene.
15.—Commission to the Presbyterie of Edinburgh.
 Miscellaneous Historical Documents,
RELATIVE TO THE ECCLESIASTICAL AND POLITICAL
EVENTS IN SCOTLAND—1639.
 1639.—January 18-29.
1. Missive anent the King’s coming to York to the
Privy Council of Scotland.162
Apud Edinburgh, 29 Januarii 1639—Sederunt,
Thesaurer, Wintoun, Aduocat,
Mar, Elphinston, Treʳ Deput,
Murray, Naper, Justice Gʳᵃˡˡ,
Argyle, Clerk Regʳ, Justice Clerk.

The whilk day the Missive Letter under written, signed be the
Kings Majestie, and direct to the Lords of Privie Councill, was
presentit to the saids Lords and read in their audience, of the whilk
the tennor followes:—
Charles R.—Right trusty and right weill belovit cousine and
counsellor, &c., We griet yow weill. Whereas we intend to repare, in
person, to York, about Easter next, that we may be the more neare
to that our kingdome, for accommodating our affaires there in a
faire maner, which course we allwayes affected, as we still doe:
These are to advertyse yow of this our resolution, being confident
that, in the meane tyme, yow will not be wanting in that which
serves the good of our service; and as we shall acquaint yow frome
tyme to time with our further proceedings; so, if anie thing occurre
wherein yow would advise us, lett us lykewayes be acquainted
therewith, becaus we will speciallie rely upon your judgement: And
so we bid yow farewell, frome our Court at Whitehall, the 18 of
Januarie 1639. Sti. Sco.
Quhilk missive being heard and considert be the saids Lords, they
ordainit the same to be insert and registrat in the booke of Privie
Counsell.
 1639.—January 26.
2. Letter from the King to the Nobility of England.163
Charles Rex,
Right Trusty and Right Welbeloved Cousin, We greet you well. The
late Disorders in Our Realm of Scotland, began upon pretence of
Religion, but now appearing to have been raised by Factious spirits,
and fomented by some few ill and traiterously affected particular
Persons, whose aim hath been, by troubling the Peace of that our
Kingdom, to work their own private ends, and indeed to shake off all
Monarchicall Government, though We have often assured them, that
We resolved to maintain constantly the Religion established by the
Laws of that Kingdom, is now growen to that height and dangerous
consequence, that under those sinister pretences, they have so far
seduced many of our People there, as great and considerable Forces
are raised and assembled in such sort, as we have reason to take
into consideration the Defence and Safety of this Realm of England;
and therefore upon due and mature consultation with the Lords of
our Council, We have resolved to repair in our Roial Person to the
Northern parts of this our Realm, there (by the help of Almighty
God, and the assistance of our good Subjects) to make resistance
against any invasion that may happen.
And to the end that this Expedition may be as effectual as we
design, to the Glory of God, the Honour and safety of Us, and of this
our said Kingdom of England, We have directed that a considerable
Army both of Horse and Foot, should be forthwith levied out of all
the Shires to attend Us in this Action, wherein we nothing doubt, but
the Affection, Fidelity, and Courage of our People shall well appear.
In the mean time, we have thought fit, hereby to give you notice
of this our Resolution, and of the state of our Affairs, and withall
hereby to require You to attend Our Royal Person and Standard at
Our City of York, by the first day of April next ensuing, in such
Equipage, and such Forces of Horse, as your Birth, Honour, and your
Interest in the publick Safety do oblige you unto, And as we do and
have reason to expect from you. And this our Letter shall be as
sufficient and as effectual a Warrant and Discharge unto you for the
putting of your selfe, and such as shall attend you, into Arms, and
Order as aforesaid, as if you were authorised thereunto by our Great
Seal of England. And we do require you to certifie Us under your
hand within fifteen days next after the receit hereof, what Assistance
we shall expect from you herein, and to direct the same to one of
our Principal Secretaries of State. Given under our Signet at our
Palace of Westminster the 26th day of January in the fourteenth
Year of our Raign.
Exam. P. Warwick.
 1639.—February 15.
3. The King’s Letter to the Nobility.164
[This letter, though of a later date than the one which preceded it,
is precisely of the same tenor, in all respects, and seems, therefore,
to have been sent as a proof of the Kings settled purpose In regard
to the expedition. It is, therefore, omitted as superflous.]
 1639.—February 20.
4. Extract from the King’s Proclamation.165
This proclamation sets forth “How traiterously some of the
Scottish Nation had practiced to pervert his Loyal Subjects of this
Realm, by scattering abroad their Libellous and Seditious Pamphlets,
mingling themselves at their publick meetings, and reproaching both
his Person and Government; That he had never any intention to alter
their Religion or Laws, but had condescended unto more for defence
thereof than they had reason to expect; That they had rejected the
Band and Covenant which themselves had prest upon the people,
because it was commended to them by his Authority; and having
made a Covenant against God and him, and made such Hostile
preparations, as if he were their sworn Enemy, and not their King;
That many of them were men of broken Fortunes, who because they
could not well be worse, hoped by engaging in this War to make
themselves better; That they had assumed unto themselves the
power of the Press, one of the chief markes of the Regal Authority,
prohibiting to Print what he commanded, and commanding to Print
what he prohibited, and dismissing the Printer whom he had
established in that Kingdom; That they had raised Arms, blockt up
and besieged his Castles, laid Impositions and Taxes upon his
people, threatned such as continued under Loyalty, with force and
violence; That they had contemned the Authority of the Council-
Table, and set up Tables of their own, from which they send their
Edicts throughout all parts of the Kingdom, contrary to the Laws
therein established, pretending in the mean time that the Laws were
violated by himself; That the question was not now, whether the
Service-Book should be received or not, or whether Episcopacy
should continue or not, but whether he were King or not? That many
of them had denied the Oaths of Supremacy and Allegiance (for
which some of them had been committed) as inconsistent and
incomptable with their holy Covenant; That being brought under a
necessity of taking Arms, he had been traduced in some of their
writings for committing the Arms he had then raised, into the hands
of professed Papists, a thing not only dishonourable to himself, and
the said noble persons, but false and odious in it self; That some of
power in the Hierarchy had been defamed for being the cause of his
taking Arms to invade that Kingdom, who on the contrary had been
only Councellors of peace, and the chief perswaders (as much as in
them lay) of the undeserved moderation wherewith he had hitherto
proceeded toward so great Offenders; That he had no intent by
commending the Service-Book unto them to innovate any thing at all
in their Religion, but only to create a conformity between the
Churches of both Kingdoms, and not to infringe any of their Liberties
which were according to the Laws; That therefore he required all his
loving Subjects not to receive any more of the said seditious
Pamphlets, but to deliver such of them as they had received, into
the hands of the next Justice of the Peace, by him to be sent to one
of his Majesties principal Secretaries; And finally, That this his
Proclamation and Declaration be read in time of Divine Service in
every Church within the Kingdom, that all his People to the meanest,
might see the notorious carriages of these men, and likewise the
Justice and Mercy of all his proceedings.”
 1639.—March 1.
5. Answer to his Majesties Missive anent his
comming to Yorke.166
Apud Edinburgh, Primo Martii, 1639.—Sederunt,
Theasaurer, Lauderdaill, Clerk Regʳ,
Argile, Southesk, Aduocat,
Mar, Angus, Justice Genˡˡ,
Murray, Elphinston, Trᵉʳ Deput,
Wigton, Naper, Justice-Clerk,
Kingorne, Amant, Blackhall.

The whilk day, the Lords of Secreit Counsell ordained ane Missive
to be written to His Majestie, conteaning ane answer to his Majesties
Missive formerlie sent unto thame, and insert in the Bookes of Privy
Counsell, anent his Majesties comming to Yorke, quhilk wes
accordinglie, done of the date and tennor folowing:—
Most Sacred Soverane,
By your Majesties Letter, the 18 of Januar, your Majestie wes
graciouslie pleased, not onlie to lett us know your Majesties
resolution to come to Yorke to be so much nearer this kingdome for
accommodating your Majesties affaires heere in a faire manner,
which course your Majestie graciouslie expresseth, you still affect,
but also requires us, that if there be anie thing wherein we would
advyse your Majestie, that we sould acquaint your Majestie
therewith. Wherefore, least we sould be wanting in that dewtie
which your Majestie may justlie expect frome us as humble and
faithfull Counsellors, or seeme unworthie of the place and rowme
whiche, by your Majesties speciall favour, we injoy in the kingdome,
We cannot but acquaint your Majestie with ane Supplication given in
to us by ane great many Noblemen, Barrons, Burgesses, and others
of this Kingdome, which, for your Majesties better information, we
presume to send yow herewith. And, withall, we cannot but let your
Majestie know that, for farther cleiring thair innocencie thairof, they
have offered publicklie, at Counsell table, by thair oaths and
subscriptions, to justifie thameselves and thair intentions heerin. And
least upon this, or some suche informations, your Majestie might be
the more easilie moved to thinke upon harder courses then your
Majestie heirtofore hath beene pleased to keepe with this your
antient and native kingdome and subjects therein, we deame
ourselves bound in dewtie, and in obedience to your Royall
commandments, to represent to your Majesties wise and grave
consideration this thair Petition. And, seing the peace of your
Majesties Government, wherein consisteth our earthlie happenes,
and wealfare of the kingdome dependeth upon your Majesties
resolutions, and the course yow sall be graceouslie pleased to keepe
in the prosecution of thir maters now in hand, We humblie supplicat
your Majestie, in your accustomed fatherlie care of the good and
preservation of this your antient kingdome, and of your faithfull
subjects therein, to resolve upon sume suche course as, without
force of armes or showing of your princelie power, deplorable estate
of this kingdome may be settled, whereby your Majestie may
receave contentment, and we, your humble and faithfull subjects,
may injoy the wounted blinkes of your Majesties favour in ane
happie and peaceable Government. And so, with our humble and
heartie prayer to God to direct your Majestie in this great and
important busines after suche maner as sall be most agreable to
your Majesties honour and the peace of the kingdome, we rest, &c.
Edinburgh, Primo Martii, 1639.
Sic Subscribitur.
TRAQUAIRE,
Argile, Mar, Murray, Wigton, Kinghorne, Lauderdaill, Southesk,
Angus, Elphinston, Naper, Amont, J. Hay, Sʳ Thomas Hop, W. E.
Johnston, Ja. Carmichaell, Hamilton, Blackhall.
 1639.—March 15-22.
6. Another Missive anent his Majesties comming to
Yorke.167
Apud Halyrudhous, 22 Martii 1639.—Sederunt,
Thesaurer, Justice Genᵃˡˡ, Treʳ Deput,
Mar, Aduocat, Justice Clerk.
Dumfreis,

The whilk day, the Missive Letter underwritten, signed be the

Kings Majestie, and direct to the Lords of Privie Counsell, wes
presented to the saids Lords, and read in thair audience, of the whilk
the tennor followes:—
Charles R.—Right trusty, &c., We greit you well. We have
perceaved by your Letter, wherein yow make mention of that which
we expressed in a letter formerlie, of our repairing to Yorke, to be
the more neere to that kingdome for accommodating our affaires
there in a faire maner; and withall yow expresse your desire how the
deplorable estate of that kingdome might be settled without force of
armes, or showing of our princelie power. We have shewne our care
hitherto by our actions for that effect: nather ar we yitt averse frome
continuing in that course. But if, in the meane tyme, anie of our
good subjects sall suffer for thair affection to our service, in
obedience to our commands, we will be verie sensible thereof, and
have a speciall care to see thame fullie repaired. And so, expecting
that yow of our Counsell, as yow are honoured by us to be first in
place, will stryve to goe before others by your good example in
advancing of our service, we bid yow heartilie farewell, from our
Court at Whitehall, the 15 of Marche 1639.
Quhilk Missive being heard and considerit be the saids Lords, they
ordaine the same to be insert and registrat in the bookes of Privie
Counsell.
 1639.—March.
7. A Letter by the Lords of the Session to the Kings
Majestie, sent with my Lord Justice Clerk, in March
1639.168
Most Sacred Soveraigne,
The danger of the tymes wherein we live threatening dreadfull
desolation of this our ancient and native kingdome, and the
conscience of our humble duetie which we owe to your Majestie, our
dear and dread Soveraigne, and to this realme, whereof we are
feeling members, honoured be your Majestie to be Counsellours and
Judges therein, hes constrained us in this case, so important and
pressing, to bemoane to your sacred selfe, the present calamitie and
apparent insueing of more. God, who hes established in your sacred
persone the just and lawfull right of regall inheritance, hes also filled
your Majestie with all other induements necessar to the Royall
calling; your Majestie, under God, may sollie allay the terrours of the
menassing stormes; and without the sunschine of your graceous and
calme countenance, this land, and the inhabitants thereof, must
become quicklie miserable. The causes are better knowen to your
Majestie then that they neid relation. When your Majestie was
pleased to indict a Generall Assembly, we and most parte of all your
good subjects of this Kingdome, wer overjoyed in expectation that
the doubts in religious worship and Kirk Government, whilk was
tossed to and fro this whyle bygone, should have then beine cleirlie
setled; and although the greater part of your people be weill pleased
with the constitutions therein concluded, yet your Majesties
displeasure against that Assembly, and the proceedings thereof, and
your expresse dislyke of these who adheres to the same, and the
fearfull consequences therefra like to ensue, hes turned all the hopes
of comfort which we expected, in sorrowes and teares. When
Princes stand in doubt of their people, and their subjects stand in
doubt of their Prince, if not tymelie remeaded, prove difficill
remeadable. To goe on at ance with deliberation, your Majestie may
be pleased to pardon us to averre, that in this they are but badd
Counsellours, and no better patriots, who will advise your Majestie
to add oyle and fewall to the fire. Violence and armes are pleased
amongst desperat remeadies, proving oftner worse then the disease.
To speake trueth ingenuouslie becomes all men, and us mainlie
more then uthers, speaking to our King, and in a matter importing
no lesse nor the universall fall or standing of this nation, and
apprehended by most parte of the leidges to reflect on religione and
conscience, which seldome are forced with successe. Who does
insinuat to your Majestie that the opposers to the proceedings of
Glasgow doe surpasse in number, and in uther considerable
respects, such as adheres to the same, we veritablie avow, in our
alledgance, that they vent unwarrantable suggestions, which may
provock the Princes wrath against his people, and does foment
meanes for the overthrow of the peace of this Kirk and Kingdome. It
is over britle a foundation whereupon to gadge the honour and
safetie of your sacred persone, and to build conclusions of warre;
and we should not hold ourselves for loyall subjects, if we should not
say these informations wer contrare to trueth. Yet your Majestie is
knowne to the world to be ane Prince prudent and moderat, who will
not be drawen from that laudable forme of raigning which was ever
familiar to your Majesties selfe, and to your royall Father of blessed
memorie, who worthilie gloried in the title of ane pacifick King; for
the throne of Kings (says that wise King) is established by Justice
and righteousnes; and therefore we must, on the knies of our
hearts, supplicat your sacred Majestie, in the bowels and mercies of
our blessed Saveour, to be pleased to forbeare all purpose of warre,
and so to prevent the evills of dispaire and necessitie; and for that
effect, that your Majestie may be pleased to close your ears against
all contrarie enducements. Your Majestie is Vicegerent to Almichtie
God, whose mercies and compassions, although immutable, are
proponed as characters of imitation to Princes, so far as mortall man
may joy therein, and resemble the immortall God.
 These our grave and submisse supplications, we begg, in all
humilitie, that your Majestie may be pleased graceouslie [to receive],
which we have sent to your Majestie by this bearer the Justice-Clerk,
who is ane of our number, to whom we have committed our
Instructions with trust: And we shall never cease to offer up our
fervent prayers to Him by quhom Kings reigne, for preservation of
your sacred persone, and the continowing felicitie of your long and
happie reigning over us, and thereafter of your royall posteritie, so
long as the world shall endure.
The Instructions are—
1. To represent to His Majestie that latelie we have presumed, in
all humilitie, to write to His Majestie to the same sence of the letter
now sent, but we are informed the Letter hes never comed to His
Majesties hands, but hes bein miscarried, and hath bein withdrawen,
by what meanes we know not.
2. To shew His Majestie that, for any thing can appeare to us,
these thinges that are now in question are urged by all as moved
thereto, that are by the persuasion of their consciences, they
esteeming them poyntes of their faith; and if force be used, all are
persuaded, and so proves, that it is not for these poynts now in
question only, but for encroaching upon religion in ane higher degrie
then is pretendit.
3. That His Majestie, in this case, may be pleased to take it to his
royall consideration, what successe persute of armes hes had in all
uther Kingdomes against men for matters of conscience, truelie, or
taken by them to be such; and that bloodie warres have ever bein to
harden the Spirits of men to opposition in matters of conscience,
and to increase their number.
4. That, if our neighbour nation doe invaid this countrie, it will
assuredlie be taken be all Scotsmen, albeit not affected the present
way, for a nationall quarrell; and all will strive as ane man to defend
themselves as for their lives, estates, and liberties of the countrie.
 5. That the countrie is also joyned togither, now that few or none
of them most reserved, can be drawen together to oppone the
countrie in this cause.
6. To represent to His Majestie the proffer made by the bodie of
the Kingdome to imploy their readiest services, lives, lands, honours,
and quhatsoever is dearest to them in this world, for His Majesties
service, and lay the same in at his Royall feete, to be disposed at his
pleasure—they being satisfied in matters of religion and conscience,
in which was performed in our presence by the great asseverations
of many considerable persons amongst them, and which we are
persuaded fullie to be true.
 1639.—March.
8. The Oath that they urged upon the Scotts Men at
London.169
I doe faithfullie swear and promise that I doe honour and obey my
Soveraigne Lord, King Charles, and will bear faith and true
alleadgance to him, and defend and mentaine him and his royall
power and auctoritie; and that I will not bear armes, or doe any
rebellion or hostile act against his Majestie, or protest against any of
His Majesties Royall Commands, but submitting myselfe in all due
obedience therunto; and that I will not enter into any Covenant,
oath, or band, for mutuall defence and assistance of any persone or
persones whatsoever, contraire to what I have herein sworne,
professed, and promised: So help me God in Christ Jesus.
 1639.—April 2.
9. Letter from the King to Hamilton.170
Hamilton,
I received yours but this morning, to which before I answer, I
must tell you News: First, that Jacob Ashly has possessed Berwick
with 1000 Foot and 60 Horse, and Carlisle is likewise possessed by
My Lord Clifford with 300 men; Secondly, I have commanded
Traquair to keep his Chamber, until he give me an account how he
left Dalkeith, without striking one stroke, and before any Cannon
was brought before it, having left the Ammunition (not destroyed) to
their reverence, and likewise the Regalia: of this more by the next.
Now for Answer, I have given the Proclamation to be written over by
the Clerk-Register, with the General Oath, both which you shall have
with all speed: for your Military Oath, I like it extreme well, as
likewise your opinion for detaining the Patents of Honours until the
Country be settled; for your Brother, certainly if you had forgotten
him I should not, but have remembered my old Engagement; and
for Dalliel, indeed he deserves well; yet methinks a Viscounty may
serve at this time, that I may have something more to give upon
further occasion: and so I rest
Your assured constant Friend,
Charles R.
York, 2 Apr. 1639.
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com