Desktop version

Home arrow Computer Science arrow Securing Systems Applied Security Architecture and Threat Models

I Introduction

The Lay of Information Security Land

[S]ecurity requirements should be developed at the same time system planners define the requirements of the system. These requirements can be expressed as technical features (e.g., access controls), assurances (e.g, background checks for system developers), or operational practices (e.g., awareness and training).1

How have we come to this pass? What series of events have led to the necessity for pervasive security in systems big and small, on corporate networks, on home networks, and in cafes and trains in order for computers to safely and securely provide their benefits? How did we ever come to this? Isn’t “security” something that banks implement? Isn’t security an attribute of government intelligence agencies? Not anymore.

In a world of pervasive and ubiquitous network interconnection, our very lives are intertwined with the successful completion of millions of transactions initiated on our behalf on a rather constant basis. At the risk of stating the obvious, global commerce has become highly dependent upon the “Internet of Things.”2 Beyond commerce, so has our ability to solve large, complex problems, such as feeding the hungry, understanding the changes occurring to the ecosystems on our planet, and finding and exploiting resources while, at the same time, preserving our natural heritage for future generations. Indeed, war, peace, and regime change are all dependent upon the global commons that we call “The Public Internet.” Each of these problems, as well as all of us connected humans, have come to rely upon near-instant connection and seamless data exchange, just as each of us who use small, general-purpose computation devices—that is, your “smart phone,”—expect snappy responses to our queries and interchanges. A significant proportion of the world’s 7 billion humans[1] have become interconnected.

And we expect our data to arrive safely and our systems and software to provide a modicum of safety. We’d like whatever wealth we may have to be held securely. That’s not too much to expect, is it?

We require a modicum of security: the same protection that our ancestors expected from the bank and solicitor. Or rather, going further back, these are the protections that feudal villages expected from their Lord. Even further back, the village or clan warriors supposedly provided safety from a dangerous “outside” or “other.”

Like other human experiments in sharing a commons,[2] the Internet seems to suffer from the same forces that have plagued common areas throughout history: bandits, pirates, and other groups taking advantage of the lack of barriers and control.

Early Internet pundits declared that the Internet would prove tremendously democratizing:

As we approach the twenty-first century, America is turning into an electronic republic,

a democratic system that is vastly increasing the people’s day-to-day influence on the

decisions of state . . . transforming the nature of the political process . . .3

Somehow, I doubt that these pundits quite envisioned the “democracy” of the modern Internet, where salacious rumors can become worldwide “facts” in hours, where news about companies’ mistakes and misdeeds cannot be “spun” by corporate press corps, and where products live or die through open comment and review by consumers.

Governments are not immune to the power of instant interconnectedness. Regimes have been shaken, even toppled it would seem, by the power of the instant message. Nation-state nuclear programs have been stymied through “cyber offensives.” Corporate and national secrets have been stolen. Is nothing on the Internet safe?

Indeed, it is a truism in the Age of the Public Internet (if I may title it so?), “You can’t believe anything on the Internet.” And yet, Wikipedia has widely replaced the traditional, commercial encyclopedia as a reference source. Wikipedia articles, which are written by its millions of participants—“crowd-sourced”—rather than being written by a hand-selected collection of experts, have proven to be quite reliable, if not always perfectly accurate. “Just Good Enough Reference”? Is this the power of Internet democracy?

Realizing the power of unfettered interconnection, some governments have gone to great lengths to control connection and content access. For every censure, clever technicians have devised methods of circumventing those governmental controls. Apparently, people all over the world prefer to experience the content that they desire and to communicate with whom they please, even in the face of arrest, detention, or other sanction.

Alongside the growth of digital interconnection have grown those wishing to take advantage of the open structure of our collective, global commons. Individuals seeking advantage of just about every sort, criminal gangs large and small, pseudo-governmental bodies, cyber armies, nation-states, and activists of every political persuasion have all used and misused the openness built into the Internet.

Internet attack is pervasive. It can take anywhere from less than a minute to as much as eight hours for an unprotected machine connected to the Internet to be completely compromised. The speed of attack entirely depends upon at what point in the address space any of the hundreds of concurrent sweeps happen to be at the moment. Compromise is certain; the risk of compromise is 100%. There is no doubt. An unprotected machine that is directly reachable (i.e., has a routable and visible address) from the Internet will be controlled by an attacker given a sufficient exposure period. The exposure period has been consistently shortening, from weeks, to days, then to hours, down to minutes, and finally, some percentage of systems have been compromised within seconds of connection.

In 1998, I was asked to take over the security of the single Internet router at the small software house for which I worked. Alongside my duties as Senior Designer and Technical Lead, I was asked, “Would you please keep the Access Control Lists (ACL) updated?” Why was I chosen for these duties? I wrote the TCP/IP stack for our realtime operating system. Since supposedly I knew something about computer networking, we thought I could add few minor maintenance duties. I knew very little about digital security at the time. I learned.

As I began to study the problem, I realized that I didn’t have a view into potential attacks, so I set up the experimental, early Intrusion Detection System (IDS), Shadow, and began monitoring traffic. After a few days of monitoring, I had a big shock. We, a small, relatively unknown (outside our industry) software house with a single Internet connection, were being actively attacked! Thus began my journey (some might call it descent?) into cyber security.

Attack and the subsequent “compromise,” that is, complete control of a system on the Internet, is utterly pervasive: constant and continual. And this has been true for quite a long time. Many attackers are intelligent and adaptive. If defenses improve, attackers will change their tactics to meet the new challenge. At the same time, once complex and technically challenging attack methods are routinely “weaponized,” turned into point-and-click tools that the relatively technically unsophisticated can easily use. This development has exponentially expanded the number of attackers. The result is a broad range of attackers, some highly ingenious alongside the many who can and will exploit well-known vulnerabilities if left unpatched. It is a plain fact that as of this writing, we are engaged in a cyber arms race of extraordinary size, composition, complexity, and velocity.

Who’s on the defending side of this cyber arms race? The emerging and burgeoning information security industry.

As the attacks and attackers have matured, so have the defenders. It is information security’s job to do our best to prevent successful compromise of data, communications,

1

the misuse of the “Internet of Things.” “Infosec”[3] does this with technical tools that aid human analysis. These tools are the popularly familiar firewalls, intrusion detection systems (IDS), network (and other) ACLs, anti-virus and anti-malware protections, Security Information and Event Managers (SIEM), the whole panoply of software tools associated with information security. Alongside these are tools that find issues in software, such as vulnerability scanners and “static” analysis tools. These scanners are used as software is written.[3]

Parallel to the growth in security software, there has been an emerging trend to codify the techniques and craft used by security professionals. These disciplines have been called “security engineering,” “security analysis,” “security monitoring,” “security response,” “security forensics,” and most importantly for this work, “security architecture.” It is security architecture with which we are primarily concerned. Security architecture is the discipline charged with integrating into computer systems the security features and controls that will provide the protection expected of the system when it is deployed for use. Security architects typically achieve a sufficient breadth of knowledge and depth of understanding to apply a gamut of security technologies and processes to protect systems, system interconnections, and the data in use and storage: Securing Systems.

In fact, nearly twenty years after the publication of NIST-14 (quoted above), organizations large and small—governmental, commercial, and non-profit—prefer that some sort of a “security review” be conducted upon proposed and/or preproduction systems. Indeed, many organizations require a security review of systems. Review of systems to assess and improve system security posture has become a mandate.

Standards such as the NIST 800-53 and ISO 27002, as well as measures of existing practice, such as the BSIMM-V, all require or measure the maturity of an organization’s “architecture risk assessment” (ARA). When taken together, it seems clear that a security review of one sort or another has become a security “best practice.” That is, organizations that maintain a cyber-security defense posture typically require some sort of assessment or analysis of the systems to be used by the organization, whether those systems are homegrown, purchased, or composite. Ergo, these organizations believe it is in their best interest to have a security expert, typically called the “security architect.”[3]

However “security review” often remains locally defined. Ask one practitioner and she will tell you that her review consists of post-build vulnerability scanning. Another answer might be, “We perform a comprehensive attack and penetration on systems before deployment.” But neither of these responses captures the essence and timing of, “[S]ecurity requirements should be developed at the same time system planners define the requirements of the system."4 That is, the “review,” the discovery of “requirements” is supposed to take place proactively, before a system is completely built! And, in my experience, for many systems, it is best to gather security requirements at various points during system development, and at increasing levels of specificity, as the architecture and design are thought through. The security of a system is best considered just as all the other attributes and qualities of the system are pulled together. It remains an ongoing mistake to leave security to the end of the development cycle.

By the time a large and complex system is ready for deployment, the possibility of structural change becomes exponentially smaller. If a vulnerability (hole) is found in the systems logic or that its security controls are incomplete, there is little likelihood that the issue can or will be repaired before the system begins its useful life. Too much effort and resources have already been expended. The owners of the system are typically stuck with what’s been implemented. They owners will most likely bear the residual risk, at least until some subsequent development cycle, perhaps for the life of the system.

Beyond the lack of definition among practitioners, there is a dearth of skilled security architects. The United States Department of Labor estimated in 2013 that there would be zero unemployment of information security professionals for the foreseeable future. Demand is high. But there are few programs devoted to the art and practice of assessing systems. Even calculating the risk of any particular successful attack has proven a difficult problem, as we shall explore. But risk calculation is only one part of an assessment. A skilled security architect must bring a wealth of knowledge and understanding—global and local, technical, human, organizational, and even geopolitical— to an assessment. How does a person get from here to there, from engineer to a security architect who is capable of a skilled security assessment?

Addressing the skill deficit on performing security “reviews,” or more properly, security assessment and analysis, is the object of this work. The analysis must occur while there is still time to make any required changes. The analyst must have enough information and skill to provide requirements and guidance sufficient to meet the security goals of the owners of the system. That is the goal of this book and these methods, to deliver the right security at the right time in the implementation lifecycle. In essence, this book is about addressing pervasive attacks through securing systems.

  • [1] As of this writing, the population of the world is just over 7 billion. About 3 billion of thesepeople are connected to the Internet.
  • [2] A commons is an asset held in common by a community—for example, pasture land thatevery person with livestock might use to pasture personal animals. he Public Internet is anetwork and a set of protocols held in common for everyone with access to it.
  • [3] hough these may be called a “security engineer,” or a “security analyst,” or any number ofsimilar local variations.
  • [4] hough these may be called a “security engineer,” or a “security analyst,” or any number ofsimilar local variations.
  • [5] hough these may be called a “security engineer,” or a “security analyst,” or any number ofsimilar local variations.
 
Source
< Prev   CONTENTS   Source   Next >

Related topics