Chapter 9
Applications, Data, and Cloud Security

---

THE SSCP EXAM OBJECTIVES COVERED IN THIS CHAPTER INCLUDE:

• Domain 7: Systems and Application Security
  • 7.2: Implement and operate endpoint device security
  • 7.4: Understand and configure cloud security
  • 7.5: Operate and maintain secure virtual environments

---

Now that we've got a secure infrastructure under our user's work spaces, how do we keep their work from being its undoing? People need to use that infrastructure to accomplish the goals and objectives of the business or organization; they get that value-adding work done by taking data in, manipulating it, creating new data with it, and outputting it in ways that inform and enable action at a profit. People get all of that value-added work done by using application programs, or apps. This combination of software, data, and human interaction can keep the overall information systems secure, expose the business to substantial vulnerabilities (and liabilities!), or both in combination.

At one end of this problem are vendor-provided resources such as applications, data, and services; at the other are end user–created apps, formulas buried in spreadsheets, macros, webpages—the list of possible risk vectors is endless. Then there are the risks of what incorrect data, or correct data misused, can bring to bear.

Let's see how SSCPs can bring this final technical component of our information security architectures under control.

It's a Data-Driven World…At the Endpoint

Let's face it—from the perspective of the information systems designer and builder, all of the action happens at the endpoints. These endpoints are where the real, tangible physical world of things and people is transformed by modeling, abstraction, and reduction into a handful of data values. It's where a similar handful of data values causes huge industrial equipment to move, to change its “end effectors” by swapping out one cutting tool for another, or hoisting this instead of that, and the result is physical, real change in the world we live in. There's a tangible, real, permeable barrier at the endpoint: on one side lives the world of the abstract information movers and shakers, and on the other side, “stuff happens.” Money changes hands; merchandise is picked from shelves and prepped for shipment; 40-foot containers are loaded onto ships or taken off of them and stacked just so along the wharf. People laugh or cry, are fed or go hungry on the physical side of that boundary layer; data may model their needs, their wants, their hopes and aspirations on the other. The model is not the reality. Forget this at your peril.

You, the SSCP, have a role to play within the information systems “ivory tower,” the abstract world in which data is manipulated, processed, calibrated, and combined to produce the other layers of the Data-Information-Knowledge-Wisdom pyramid. Inside the boundary, you translate business logic and security concerns into the software and data structures that implement identity management, access control, and a host of other security measures. Outside of that boundary, your work with physical and administrative controls, for example, is by nature part of the real, physical world; so are the sensor and control technologies used throughout your information security systems. The boundary itself represents the threat surface—that logical construct at which subjects attempt to cross into your virtualized data world. Data-driven logic helps you separate the legitimate attempts to enter your systems from those that are not. As the on-scene SSCP, you constantly move across the boundary as you shift your thinking across the data, control, and management planes of your organization's information architectures. (Yes, those planes—and the identity plane as well—should extend beyond just the world of the digital circuits and systems.)

But what about that boundary layer? What happens at that interface between the world you can touch and the world you can only think about? What about those two-way acts of abstraction and reification (making real) that happen across that boundary layer? And perhaps most germane to you, what is the role the SSCP plays in making that boundary safe?

That boundary layer is defined and implemented by the application programs, or apps, that users need and use to gather information, transform it, use it in making decisions, and then use it to control and monitor how well those decisions pan out. That boundary layer is many layers deep. Apps layer upon each other, using interface handlers and middleware to broker information between them and to interface with applications that are so large and feature-rich that we call them platforms—huge suites of applications programs, brought together via their underlying databases and data models, which provide broad and deep business logic capabilities to many different businesses. Salesforce, for example, provides broad, standardized capabilities in customer relationship management, business logic fulfillment, and decision support needed by businesses in almost any industry. Campus Solutions, by contrast, provides these same capabilities specifically tailored to meet the unique needs of the education and training industry; while Apollo is even more narrowly focused on the passenger air travel industry alone. These are all based on their data models; they are all data-driven embodiments of business logic. But whether an application is a huge, complex, feature-rich platform or a small, single-purpose, lightweight app on a handheld or smaller device, the action happens at the endpoints. That's where the organization makes its livelihood.

This is why this chapter separates apps and data from the infrastructures that support them. We've looked in depth at the security issues pertaining to those infrastructures in previous chapters. Many of those same issues, such as access control, pertain to the “apps and data and endpoints” view of the world as well. Yet one powerful truth remains unexplored. Endpoint security can make or break everything else you have done to manage your organization's information and decision risk.

You should feel that you're using some familiar guides and instruments to explore what might seem to be unfamiliar territory here in this chapter. In particular, we'll focus on the top layers of the OSI model, the ones that layer onto the basic four of the TCP/IP protocol stack. Know that as application builders and users, as gatherers and manipulators of data, we count on those lower layers to be cast-iron bulletproof, rock-solid secure. We have to rely on the implementations of those lower layers, and the systems and infrastructures they run on, to be doing their assigned portions of our overall information security needs for confidentiality, integrity, availability, nonrepudiation, and authorization. As users in our day-to-day operational tasks, we have to trust that others—other people and other systems—deliver their parts of the organization's total CIANA+PS needs. (You'll recall that CIANA+PS embodies the key information security attributes of confidentiality, integrity, availability, nonrepudiation, and authentication, while also addressing safety and privacy needs.) As app builders and users, we're not going to reinvent the secure transport layer here, nor are we going to work around any shortcomings in physical security. Those are rightly someone else's jobs to get done reliably (and it is management's due diligence responsibility to ensure that they are).

But…

A cost-effective allocation of risk management and risk mitigation might decide that a particular risk is best addressed at the Application layer, rather than the Physical layer, or how the Presentation layer simply cannot cope with another kind of threat and must rely on “what's above or below” to keep things safe and secure. And we'll revisit our earlier work on integrating all aspects of information security together in appropriate ways so that our awareness, our cognizance if you will, of an incipient or evolving threat incident can be met because we have effective command, control, and communications in place to deal with it.

In other words, it's at the endpoints that information turns into value-producing work and that work becomes information of value. This transformation is app-driven and app-enabled, and many times people-performed. The infrastructure may reduce our exposure to risks causing those app-driven transformations to go awry (or not); our people may be capable of keeping surprise from becoming dislocation in the face of mistakes, failures, or attacks (or not). The data we need, from inside our systems or from the outside world, does not turn into value without applications.

This is not just about information security, is it? It's about assuring the ongoing operation of business functions at the endpoints, by means of the software, data, and procedures that implement the business logic. As SSCPs, we'll need to know more about how applications software gets created, used, maintained, and then replaced; we'll also need to know a lot more about the lifecycle of the data and information as well. We'll then have to place both of these lifecycles firmly within an information systems and IT security context if we are to deliver the levels of business function and decision assurance that's needed.

We'll start our investigations of data-driven endpoint security with applications software, sometimes called apps or appliances. We'll see what it takes to build them secure, use them securely, and keep them secure. Data quality and data assurance, two sides of the same information security coin, will be our next port of call. Taking all of this into the clouds does add some complexities that SSCPs need to know how to cope with.

---

Ghosts Moving the Machines

Ian works as an instrumentation calibration and repair technician aboard one of the world's largest off-shore oil platforms, out in the frozen middle of a large body of water somewhere north of the Arctic Circle. A consortium of six different multinational corporations designed, equipped, and now staff and operate this biggest of the “big rigs.” As Ian describes it, “all of a sudden, tons of industrial machinery start moving, as if it had a life of its own. Sometimes members of the crew know what's going on; sometimes they don't. It can get scary out here.”

One of Ian's key concerns is that there is no agreed-to software or data configuration management. There are no rules, and no configuration management boards that enforce those rules. Stuff simply happens, and maybe the human crew on that rig know about the stuff before it's going to happen, and maybe they don't. These six multinational players don't “play nice,” you might say; each is too busy chasing the profit margin to worry about whether the changes in software, control parameters, or operational procedures it implements in macros, control parameter settings, and scripts work safely and harmoniously with the other five's sets of data.

Yes, data. Scripts that embody procedural steps are nothing more than data that the script execution engine swallows whole, spitting out machinery-driving commands in step with what the script asks for. If the script designer overlooked a fail-safe parameter check, then the script will run without interrogating the sensor that should be the authoritative source for that fail-safe.

So long as things work as planned, it may be cheaper and more efficient (in the short term) to operate without the overhead and delays of a configuration management system, both for applications and systems software (and hardware). A formal data modeling and control process, one that would define every control or critical parameter once and ensure that all software used it correctly, is only felt necessary when things go wrong.

Is this something that the SSCPs working in those multinationals should have concerns about? How should they address this situation?

And how does their experience, or Ian's, relate to the systems and practices your world uses?

---

Software as Appliances

Almost every computing device we use today is a general-purpose computer, one that can run programs to accomplish almost any function or task users ask it to by loading and executing programs written to achieve such functions. We often say that the only limits on what we can do with such general-purpose computers are the limits of our own imagination. Contrast this with your kitchen or home appliances; you don't ever think of your toaster as being able to wash and dry the dishes or prepare your shopping list for you, no matter how “smart” or network-enabled your kitchen is (do you?). We quickly accept that a special-purpose device, provided it does that purpose well, is often a better use of money, time, space, and energy than trying to make things too general in their capabilities. We might have a full set of pots and pans, and a stove or a cooktop, with which we can cook almost any kind of meal. But we let our smart coffee pot make our coffee when we need it, perhaps when our smart house senses we're about to get out of bed (or when we've told it we need the smell of fresh-brewed coffee as part of our wake-up call!), rather than try to over-gadget our stovetop.

This same approach of encapsulating a limited set of functions into the right combination of hardware, systems software, application software, and data brings another set of trade-offs with it that the SSCP needs to consider. Let's look at a few common examples to see just how prevalent this appliance model is today:

• Small office / home office (SOHO) routers and the modems provided by ISPs combine specialized hardware, OSs, and applications that present users with very powerful capabilities.
• Point-of-sale terminals have morphed from the smart cash register into highly portable devices used by restaurant wait staff, rental car agents, and many other businesses.
• Network attached storage (NAS) appliances package terabytes of inexpensive disk with network and server functions, bringing these capabilities into the reach of many home and small office users.
• Home entertainment, gaming, and smart home appliances bring a variety of related functions together and make them more pervasively available throughout our living spaces (yet none of them, thus far, help you in preparing your income taxes!).

Step away from the typical office environment and look at today's factory floor, and you see even more software-intensive appliances in action:

• Industrial automation and control uses a wide range of programmable control devices. Many major tasks in factory or process automation are easily broken down into well-understood steps, which are packaged or hosted into highly modularized elements.
• Medical and clinical settings combine specialized sensors to gather patient data, operate laboratory processes and instruments, and combine them with caregiver observations, orders, and interventions to provide better, safer patient care. This holistic approach to patient wellness via smarter, focused use of information is often referred to as medical informatics.
• Physical security systems combine sensors, input and display devices, and control systems to monitor the motion of people, packages, or vehicles; restrict, prevent, or authorize their further movement; and invoke other security and protection functions automatically or at the command of human security operators.

---

Does “App” Mean “Application” or “Appliance?”

Good question!

From the first introduction of cell phones in the 1980s, portable communications users wanted more functionality. Motorola's DynaTac 8000x phone hit the market in 1983, with only a very rudimentary contacts list manager built into its onboard software. This brick-sized, 2.5 lb cell phone had no real way to expand its onboard functionality, which further whetted the market's appetite for more capabilities while on the go. The limited display, processor, and storage capabilities of the first- and second-generation phones dictated that smaller, lightweight, limited-function applications were needed, as users and industry observers quickly pointed out back then. As Steve Jobs pointed out (also in 1983), a totally different software distribution business model, similar to the then-popular record stores, was the opportunity waiting in the wings to address these problems. But it was not until sometime in the first decade of the twenty-first century that the market started calling these “apps,” possibly because Apple and Microsoft, and later Google, started making them available to users via their Web-based “app stores.”

Enter the era of the smart watch, and these apps-as-applications start to take on more of an appliance look and feel. Devices like the Fitbit line of fitness trackers combine limited health measurements (like pulse rate, motion, maybe even blood pressure and respiration) with location tracking, all built around the user paradigm of a wristwatch and its date-and-time functions. When linked to a desktop or mobile phone application, such fitness trackers enable users to have greater visibility of their activities, perhaps enabling them to change habits and choices as they correlate the tracker's data with other offboard information. The question remains: is such a fitness tracker, as a package, an “appliance”? And when the tracker's user downloads and installs a software package to enable integration of offboard data more seamlessly, is that software an “app as appliance” or “app as application”?

This distinction of appliance versus application is poorly expressed in the marketplace today. It may in fact be becoming more fluid, as it shifts from a designer's paradigm to an end-user or use-case paradigm. As a user, I might build a smarter, healthier lifestyle around my fitness tracker by gathering virtual appliances together that help me stay active and fit, but this depends on those appliances plugging and playing together in simple, safe, secure, and reliable ways. As a designer, I'm focused more on the details of the interfaces, whether they be applications calls, network-enabled and data-driven, or combinations of both. As the SSCP in my household, I have to look through both lenses to meet my needs for CIANA+PS as applied to our family's fitness and lifestyle information systems—be they apps, applications, appliances, or data.

---

If there is a trend, it is to see more and more endpoint functionality being packaged, deployed, and used as appliances, rather than as “traditional” feature-rich applications. From the designer's perspective, maybe it's time for other nonmanufacturing businesses and organizations to borrow a few pages from the industrial process control playbook. Software-based or software-intensive appliances are beginning to be treated as commodities, which lets the market's need for standardized, modularized function within a particular envelope of price, performance, and reliability be met in reliable, repeatable ways.

Another trend that may be emerging is that the line between an Internet of Things (IoT) device and an appliance is blurring. As a whole domain of systems components, IoT devices have a reputation for being too simple, perhaps. Many do not support even the most rudimentary of security features and come with little or no way to update their onboard firmware or change security-related control parameters such as their default login and password. IoT device makers are feeling the pressure from the market and are starting to “smarten up” their products.

As an example, consider a modern orchard, using smart irrigation and nutrient delivery systems individualized to meet each tree's needs. Such orchards use a wide variety of Wi-Fi-enabled, GPS-savvy sensors and controls; each tree is known by its GPS coordinates; and a geographical information system (GIS) brings all of that data together. Are those sensors, the irrigation control systems, and even the uninhabited aerial vehicles (UAVs) that are flying survey and surveillance missions IoT devices, appliances, or something else? Does that distinction matter? To the orchard operators, no; their IT staff may need to differentiate the type of endpoint device based on how “dumb” or “smart” it is, and therefore whether it is a “classic IoT device” or a smarter, more capable appliance, or something else entirely.

The key takeaway for the SSCP on this is that these boundary lines between categories of devices are blurring. What remains as key differentiators might best be thought of (by the SSCP) in security-centric terms: how much that device contributes to information security solutions, compared to how much it causes or aggravates our information security problems.

Applications Lifecycles and Security

Software is the set of instructions we give to the hardware to make it do the things we need done. Your car just sits in the driveway until you instruct it to take you to work, doesn't it? You issue instructions to the car by physically interacting with its controls—door handles, ignition switch, gearshift lever, the pedals, and so on. You design that total set of instructions based on the needs of your journey, and as you saw in Chapter 3, “Integrated Information Risk Management,” you manage risks along that journey by preplanned vulnerability assessment combined with observation throughout the journey itself. This analogy is useful not only because it relates ideas to actions, but also because it reveals something about risk. Simply put, the instructions (for the journey or for a program) are easy to create—you just write them down. Making the hardware is, well, harder to do. Making hardware requires “bending metal” and other tangible actions on materials; we trust that we can always make up for shortcomings in hardware design by “fixing it later in the software” (or letting the end user cope with it procedurally). Yet experience shows that finding the logical design errors, the simple coding mistakes, or the misuse of programming language features in the code is a lot harder than finding errors in the hardware.

Don't panic—as an SSCP you do not need to become an expert programmer or a software development manager to be able to keep your company's applications software safe and secure. You do, however, need to gain a working knowledge of what it takes to develop most of the significant software applications that businesses and organizations use in order to help those developers and users keep the business running safely and securely. That boils down to knowing how and why to ask a few important questions of the software developers, maintainers, and managers you support:

• How do we identify and resolve vulnerabilities in the apps we write? In the apps we get from vendors or others?
• Do we have formalized processes for all apps across the full lifecycle, from needs identification to deployment to end users to retirement or disposal?
• How do we handle apps that end users develop?
• How do we do configuration management and control of all applications?
• Do we work to continually improve and mature those software lifecycle processes?

Any of those questions that have negative, incomplete, or unclear answers are highlighting potential risk management areas that need urgent attention.

The Software Development Lifecycle (SDLC)

When we talk about the lifecycle of a system, we are trying to include every step from first concepts through postretirement—“from cradle to grave,” as many manufacturers sometimes refer to it. As you saw in Chapter 1, “The Business Case for Decision Assurance and Information Security,” no organization operates in that hypothetically perfect world of unlimited time, resources, and budget; every step of every task, every day, must make compromises with cost, schedule, and technical satisfaction of the most important performance requirements. Systems analysis, design, development, validation testing, operational use and support, and finally retirement are no exceptions to this “golden rule” (which we might paraphrase as “without the gold, you don't get much of a system designed, built, tested, or put into use”). For software, we use the term software development lifecycle (SDLC) model as the collective name of processes, procedures, and systems used to plan, organize, manage, and direct the people processes necessary to go from ideas to design and development to in-use validated software and beyond. There are many different SDLCs in use today, and most of them are based on the waterfall model, shown in Figure 9.1. The waterfall model consists of the following major stages:

FIGURE 9.1 Waterfall software development lifecycle model

• Systems analysis is the process of capturing in human-readable form the needs for form, function, and purpose of a new information system, and grouping, structuring, and allocating those needs to broad, functional elements of software, hardware, networks and communications, people-facing processes, and other information-based processes. This phase is often called the requirements phase, as its main outcome is an agreed-to baseline set of statements about form, fit, and function that the system is required (in contractual terms) to meet. Its major output is usually a set of performance requirements, which are statements of what the system must do, and the measurement standards its functions will be assessed against, if the system (once it's built) is to meet the users' needs.
• Systems design translates the requirements for the system into a set of design elements; as such, system design makes choices about implementation approaches. The nature of the mission (the requirements) might, for example, dictate that this be a cloud-hosted, highly scalable architecture, or it might be that the mission requires most of the functionality to live in small IoT devices at the edge of the cloud or the network. System design also allocates requirements to elements of the design so that customers and users will know which features to use to accomplish business logic or mission needs.
• Development and test activities translate the system design into working software, which is verified to work correctly.
• Validation or acceptance testing provides a formal way for customers or users to see that each of the system's requirements have been correctly and completely built into the system and how they can be used to accomplish business or mission needs. Inspection and audit of the code, builds and control information, and configuration management records verify that no other functions were built into the product system—both to prevent excessive costs and to prevent backdoors or malware from sneaking in.
• Operational deployment moves the system from the developers to the users in two important ways: by installing it and having users start to “do business” with it, and by shifting the management of the systems baseline from developer-managed to user-managed. During development, the configuration management authority largely resides with the developer; once the system goes live, the business or organization's operational stakeholders now make the configuration management decisions.
• Systems replacement and retirement occurs when for whatever reason the organization chooses to stop using one set of systems and capabilities and replace that set with something else. New business needs might dictate this; increased risk exposure might also be a cause. Typically, the new systems are brought from concept to operational deployment, and then the old system is turned off, torn out, and disposed of.

Each of these critical steps in the life of a software application can present information security risks and the opportunities to manage and mitigate those risks. And it should go without saying that each of those steps involves compromises between functional requirements, safety and security needs, resources, time, budget, and risk tolerance. And if that's not enough, as you saw in Chapter 3, each time you compromise on some aspect of a system, you increase the likelihood of introducing a weakness in design that could be an exploitable vulnerability.

SDLCs and IDEs

The waterfall model might seem to suggest that all software is developed in this highly structured manner, with well-defined turnover points between each step. Major systems that have safety-critical and mission-critical functions to perform, such as military command and control systems, medical information systems, and space flight and air traffic control systems, are often built this way. It allows for a clean decision point (often called a milestone) that controls the flow of activity and attention from one phase to the next. To successfully keep such a project on schedule and within cost is difficult; the more that the real world changes the mission requirements, the more that each subsequent step is put at risk.

Most business systems, however, do not have safety of life (or the survival of a nation) riding on the successful implementation of their performance or security requirements. In fact, many businesses and nonprofit organizations have to face new and different questions arising from their marketplaces, questions that require them to change the way their applications process and present information on an almost daily basis. This requires agility in those systems themselves—the ability to put a tool to a somewhat different use than was envisioned when it was made or purchased. It also requires these systems to be more resilient—more flexible and adaptable in the face of change—than a formal, tightly controlled requirements-driven software development lifecycle can usually manage.

Integrated development environments (IDEs) have come a long way in the last three decades. An IDE provides a complete, robust set of software tools that support one programmer, a team of programmers, or many teams at once, in all phases of development, test, deployment, and support of major or minor software systems. Many software and systems vendors provide one flagship IDE product, such as Microsoft's Visual Studio, which can support many different programming languages, and even support the integration of code from “foreign” libraries (those outside of the organization and its span of administration and control). Not all software is written in and managed by an IDE, however. Personal preferences for programming languages, libraries, tool sets, and integration strategies can make it hard sometimes to find the right mix of software development talent to get the new apps built and deployed, the old ones maintained, or both; this can add up to a less-than-integrated use of an IDE.

As an SSCP, you'll run into a number of different strategies for software development, with names like Agile, Scrum, Spiral, Rapid Prototyping, Code-First Design, Test-First, and others. Don't lose sight of those key questions shown earlier. Keep Kipling's six wise men handy; keep asking how things get done, what steps are taken to identify security needs, who decides what security needs to implement, where those implementations are done, and so forth. In organizations that are perhaps more security-conscious than others, you'll actually find that the SSCP is welcome to join these discussions, throughout the lifecycle. These are organizations that are using one of many variations on the DevSecOps systems lifecycle model. DevSecOps is perhaps more of a cultural set of ideas than it is a standard; most organizations tailor it extensively as they adapt it to their needs, and as their leadership (at all levels) guides the organization to grow with it.

Why Is (Most) Software So Insecure?

It's almost an accepted part of our culture that the software we humans create is probably going to have mistakes in it. Although some of those mistakes may end up being minor inconveniences to its users, others might be exploitable vulnerabilities. Why?

First, the writing of software is a creative human process. We take ideas about functions we want to perform, translate those ideas into designs, and translate those designs into higher-level programming languages; and along the way, we create the user manuals, data structures, and everything else that should complete the bundle of new business capabilities. Since none of us are perfect, mistakes happen in each of these products.

Many of the mistakes made during design and development are preventable:

• Poor design practices. Applications are complex programs that designers build up from hundreds, perhaps thousands of much smaller, simpler units of code. This decomposition of higher-level, more abstract functions into simpler, well-bounded lower-level functions is the heart of any good design process. When designers consistently use proven and well-understood design rules, the designs are more robust and resilient—that is, their required functions work well together and handle problems or errors in well-planned ways.
• Inconsistent use of design patterns. A design pattern is a recommended method, procedure or definition of a way to accomplish a task. Experience and analysis have shown us that such design patterns can be built successfully and used safely to achieve correct results. Yet many programs are developed as if from scratch, as if they are the first-ever attempt to solve that problem or perform that task. Assembling hundreds or thousands of such “first-time” sets of designs can be fraught with peril—and getting them to work can be a never-ending struggle.
• Poor coding practices. Since the 1940s, we've known that about 20 classes of bad programming practice can lead to all-too-familiar runtime errors and exploitable vulnerabilities. The software industry teaches programmers these “thou shalt nots” of programming; still, they keep showing up in business applications and systems software.
• Inconsistent use (or no use at all) of proven, tested design and code libraries. Software reuse is the process of building new software from modules of code that have been previously inspected, tested, and verified for correct and safe execution. Such design and code libraries, when published by reputable development teams, are a boon to any software development effort—as long as the right library elements are chosen for the tasks at hand and then used correctly in the program being developed. High-quality libraries can bring a wealth of security-related features built into their designs and code; in many cases, the library developer provides ongoing technical support and participates in common vulnerability reporting with the information systems security community. Sadly, many software teams succumb to schedule and budget pressures and use the first bit of cheap (or free) code that they find on the Internet that seems to fit their needs. Sometimes, too, application programmers speed-read the high-level documentation of a library or a library routine and accept what they read as proof that they've found what they need. Then they just plug it into their application and pray that it works right, never taking the time to read the code itself or verify that it will correctly and safely do what they need it to do and do nothing else in the process.

This lack of discipline in using proper and proven design practices and patterns, as well as poor coding practices (or the lack of coding standards) can often produce spaghetti code, so called because trying to read it and follow its logic is as easy as following one strand of spaghetti when it's in a plateful on your dinner dish.

---

Security “Baked In” to the Software, Right from the Start?

Strange as it may seem, most applications software is specified, designed, written, and tested by people who rather innocently assume that the world is not a dangerous place. So how do you, as a non-code-bending, non-software-trained SSCP, help your company or organization get more defensive in the ways that it builds and maintains its software? A blog post by the editorial team at Synopsys, in their Software Architecture and Design blog at www.synopsys.com/blogs/software-security/principles-secure-software-design/, highlights four key points to ponder:

1. Be paranoid. Know that somebodies, somewhere, are out to get you. Lots of them.
2. Pay attention to abuse cases, instead of just the “business normal” use cases, as sources of your functional and nonfunctional requirements. (They go on to mention three fallacies that lead to complacency about security needs among software developers.)
3. Understand that small vulnerabilities cascade together to become just as disruptive as a few large vulnerabilities can be.
4. Build things securely so that they last. Build for posterity.

One major problem has been that for decades, the software industry and academia have assumed that managers and senior designers are responsible for secure software design and development. It's no good teaching brand-new programmers about it, because they don't manage software projects, according to this view. As a result, an awful lot of insecure software gets written, as bad habits get engrained by use.

A great resource to learn with is the Open Web Application Security Project (OWASP), at www.owasp.org. OWASP is a nonprofit source of unbiased, vendor-neutral, and platform-agnostic information, and provides advice and ideas about the right ways to “bake in” security when designing Web apps, such as its annual update of its list of the most frequent software security vulnerabilities, at https://owasp.org/Top10/.

As the SSCP, you are the security specialist who can help your organization's software developers better appreciate the threat, recognize the abuse cases, and advocate for penetration-style security testing during development—not just after deployment!

Baking the security in from the start of software development requires turning a classic programmer's paradigm inside-out. Programmers are trusting souls; they trust that others will do their jobs correctly. They trust that users will “do the right thing,” that network and systems security will validate the user, or that access control done by someone else will prevent any abuses. (Managers like this paradigm, too, because it shifts costs and efforts to other departments while making their jobs simpler and easier.) Instead, it's more than high time to borrow a page from the zero trust school of thought for networks:

Trust no one, trust no input data, ever, and verify everything before you use it.

---

Next, we manage that process with other software—design tools, source code editors, compilers, integrated development environments, test systems, shells and data, configuration management tools, and analysis and inspection tools. This software, too, can have its own share of mistakes. It's also procedurally intensive work to plan, manage, build, test, integrate, and deliver major application packages.

Schedule concerns and budget limitations provide constraints on the development and test process. Usually, the new software has a hard and fast delivery date already set for it; the costs that delaying the delivery date are often too painful to tolerate. There's also a limit on how much money can be spent on testing, reprogramming to repair the errors, and retesting.

But that's not all. As we push on from design into coding, other common sources of data errors plague many software projects:

• Weak enforcement of data typing and data modeling during software development. A major business platform application, such as an enterprise resource planning (ERP) system, might have tens of thousands of identifiers—names for fields in records, for record types, for variables used in the software internally, and the like.
  • Data modeling is a formal process that translates the business logic into named data elements. It formalizes the constraints for initialization of each data item; how new values are input, calculated, produced, and checked against logical constraints; and how to handle errors in data elements. For example, one constraint on a credit card number field might specify the rules for validating it as part of a data set (including cardholder name, expiration date, and so forth); related constraints would dictate how to handle specific validation problems or issues.
  • Data typing involves the rules by which the programmer can write code that works on a data item. Adding dollars to dates, for example, makes no sense, yet preventing a programming error from doing this requires data typing rules that define how the computer stores calendar dates and monetary amounts, and the rules regarding allowable operations on both types taken together. Organizations that manage their information systems with robust data dictionaries and use rigorously enforced data typing in their software development tend to see fewer exploitable errors due to data format, type, or usage errors.
• Inconsistent or no data quality efforts during operational use. Think about what should happen when a clerk enters a customer's name into a data input screen but misspells it in the process; if it's an existing customer, the system ought to find a close match and query the clerk to identify the correct customer. The failure of this “preexisting match test” logic then would prompt the clerk to ask, “Are you a new customer?” and only then create a new customer record in the system. This is an example of taking the business logic in the data dictionary (as a design standard for business processes) and enforcing it when the logic is used day to day. Customers change their address, even their name, sometimes a lot more often than mere programmers assume people will do; data quality focuses on keeping all of the related data together, logically consistent, correct, and up to date. (We'll look at some practical approaches to data quality later in this chapter.) Yet despite the proven payback of data quality efforts to almost any business, many organizations see it as a cost to be avoided; they simply trust that their operators, or sales clerks, or customers will find the errors and either tolerate them or fix them.

---

Data Modeling Should Reflect Security Needs

Most data modeling is driven by use cases—who needs the data, what they use it for, and what happens to the data as they use it. Overwhelmingly, this use case analysis fails to recognize the abuse cases (as noted by Synoptics earlier); as a result, the data models assume trusted subjects doing trustworthy operations upon the data. By contrast, applications that are viewed as safety-critical often spend considerable time, early in the development process, imagining what can go wrong, to identify drivers for how to keep things going right instead.

As the SSCP, perhaps you can bring your understanding of threat modeling to your organization's data modelers. Start small, perhaps over lunch or a coffee, and explore the possibilities for collaboration.

---

Hard to Design It Right, Easy to Fix It?

This is perhaps the most pernicious thought that troubles every software development team, and every user of the software that they depend on in their jobs and in their private lives. Hardware, after all, is made of metal, plastic, glass, rubber, and dozens of other physical substances. Changing the hardware is hard work, we believe. A design error that says that our SOHO router overheats and burns out quickly, because we didn't provide enough ventilation, might require a larger plastic enclosure. That design change means new injection molds are needed to cast that enclosure's parts; new assembly line processes are needed, maybe requiring changes to the fixtures and tooling; and new shipping and packing materials for the empty enclosure and the finished product will be needed. That's a lot of work, and a lot of change to manage! But changing a few lines of code in something that exists only as a series of characters in a source code file seems easy by comparison.

This false logic leads many managers, users, and programmers to think that it's easy and simple to add in a missing feature, or change the way a function works to better suit the end user's needs or preferences. It's just a simple matter of programming, isn't it, if we need to fix a bug we discovered after we deployed the application to our end users?

Right?

In fact, we see that software development is a constant exercise in balancing trade-offs:

• Can we really build all of the requirements our users say they need?
• Can we really test and validate everything we built and show that it meets the requirements?
• Can we do that for a price that we quoted or contracted for and with the people and development resources we have?
• Can we get it all done before the marketplace or the real world forces us to change the build-to requirements?

As with any project, software development managers constantly trade off risks versus resources versus time. Some of the risks involve dissatisfied customers when the product is finally delivered; some risks involve undetected but exploitable vulnerabilities in that product system. And all projects face a degree of uncertainty that the people, money, time, and other resources needed for development and acceptance testing won't be as available as was assumed when the project was started—or that those resources will be there to support the maintenance phase once the project goes operational.

How much security is enough to keep what sort of applications secure? As with anything else in the IT world, the information security aspects of any app should be a requirements-driven process.

CIANA+PS and Applications Software Requirements

A maxim in the software industry is that any program large or small should do what its users asked the programmers to make it do; it should do those functions well, and do nothing else at all. This is the two-edged razor blade of software validation and test. First, you need to prove that requirements the customer paid for actually get done by the software you wrote. Second, you need to prove that no other surprises, special features, or hidden bells and whistles are built into your code, just waiting for the right series of operations and inputs to bring them to life.

(One good definition of malware is software that contains such unacknowledged or undisclosed features, after all.)

So how does the SSCP, who is probably not a programmer or systems analyst after all, assess their organization's applications software from this security requirements perspective?

Our old friend CIANA+PS provides a great starting point to specify and definitize our information security needs as allocated to the applications that we use. Our systems analysis process should have allocated other functional requirements to specific applications (we don't normally expect bills to be paid to vendors or suppliers by the human resources management apps, for example). Then, as part of the design process, we decompose those functions into smaller sets of steps, and assign those sub-functional sets to elements of an application's design itself.

In a perfect world, systems analysts and designers would consult with the organization's information risk managers and get their current, detailed views on how confidentiality, integrity, authentication, nonrepudiation, and availability are related to each and every information asset that the system they're designing will come in contact with. As they flow high-level statements of need down into design-level subsystems and components, they would allocate the parts of CIANA+PS that apply to that subsystem. Then they'd build it, and test it not only against the performance requirements, but also against security, operability, and all of the other “-ilities” that become part of the ways that systems stakeholders assess project success. (All too often, of course, compromises between this perfect set of needs and the imperfect but real world of schedules and budgets end up cutting corners, or more, off of many a well-intended design, build, and test process. This can often introduce vulnerabilities into the final as-delivered system, or fail to detect and remedy them.)

From the penetration tester's perspective, or the vulnerability assessor's point of view, we can work this in the reverse direction. Take any particular function in the as-deployed information system, and see how it is actually used in day-to-day business operations. Given that high-level CIANA+PS statement, does the use of that function demonstrate what you think is adequate information security? Or is that particular function so trusting that “other functions” run by “somebody else” properly carried out the security needs? Take the simple task of an airline passenger service system accepting a boarding pass from a passenger and then signaling the gate agent that the passenger is cleared to board the flight. Air transport regulations, safety, and security all drive the due care and due diligence responsibilities that the airline and airport operators must meet as a part of loading the right passengers onto the right flight at the right time. CIANA+PS might dictate a whole host of requirements, which might include:

• Confidentiality might require that the passenger's name, identification numbers, frequent flier numbers, etc., are not easily be seen by other passengers or bystanders in the gate area, and if further identification is required to verify that the right human being has the right boarding pass, that this can be done with due care to privacy needs.
• Authentication would require that the gate agents must sign on to the gate information system, and that their access privileges be authenticated as current and include their being assigned to process that particular flight at that particular gate; authentication is also the process that accepts that person X is the passenger that their boarding pass claims them to be, and thus, they are authorized to board.
• Integrity would require that any data entered or captured at the gate (such as boarding pass serial numbers) be error-checked and validated against the approved flight manifest, passenger list, and other information, right there at the endpoint (the gate and its terminal systems); then the data and its validation information are transferred to central systems for other uses as a signed, sealed bundle (to provide integrity protection while in motion).
• Nonrepudiation would demand that steps be taken to ensure that all manifested passengers who checked baggage onto the flight actually boarded it and are still on board when the order to close the cabin door is issued.
• Availability of passenger check-in as a function would dictate that there are backup (perhaps manual) processes for checking passengers onto the flight, verifying boarding passes and identification, etc., in the event that the IT system elements fail to operate during boarding.
• Safety for passengers, crew, and passenger service agents requires additional, last-minute screening of individuals' names against government-issued no-fly or security watchlists. And as Covid-19 reminded us, safety also requires verifying that each passenger and crew member has no medical issues, such as a lack of proper vaccinations.
• Privacy and data protection requirements will be reflected in procedures that flight crew, gate agents, and other personnel must use to protect printed and electronic versions of flight manifests, boarding passes, and anything pertaining to denial of boarding. This would include protection of changed or voided printed copies of tickets, boarding passes, and manifests.

---

Security Requirements: Functional or Nonfunctional?

In systems analysis, a functional requirement is one that specifies a task that must be done; the requirement may also specify how users can verify that the task has completed successfully or if one of many error conditions have occurred. For example, the requirement might state that pressing the “start engine” button causes prerequisite safety conditions to be checked, then activates various subsystems, step by step, to start the engine; failure of any step aborts the start process, returns all subsystems to their safe pre-start condition, and sends alerts to the operator for resolution. By contrast, a nonfunctional requirement states a general characteristic that applies to the system or subsystem as a whole but is not obviously present in any particular feature or function. Security requirements are often considered nonfunctional. This can be confusing, as a few requirements examples can suggest:

• Safety requirements in a factory process control system might state that “the system will require two-factor authentication and two-step manual selection and authorization prior to allowing any function designated as safety-critical to be executed.” As a broad statement, this is hard to test for; yet, when allocated down to specific subfunctions, either these specific verification steps are present in the module-level requirements, then built into the design, and observable under test, or they are not. Any as-built system element that should do such safety checks that does not is in violation of the requirements. So is such a safety requirement functional or nonfunctional?
• Confidentiality requirements in a knowledge bank system might state that “no unauthorized users can view, access, download, or use data in the system.” This (and other) requirements might drive the specification, design, implementation, and use of the identity management and access control systems elements. But does the flow-down of this requirement stop there? Or do individual applications inherit a user authentication and authorization burden from this one high-level requirement?
• Nonrepudiation requirements for a clinical care system could dictate that there must be positive control for orders given by a physician, nurse practitioner, or other authorized caregiver, both as record of care decisions and as ways to prevent an order being unfilled or not carried out. The log of orders given is a functional requirement (somebody has to build the software that builds the log each time an order is entered). But is the nonrepudiation part functional or nonfunctional?

Many systems analysts will consider any requirement allocated to the human elements of the system as nonfunctional, since (they would argue) if the software or hardware isn't built to execute that function, that function isn't really a deliverable capability of the system. This also is the case, they'd argue, for functions “properly” allocated to the operating system or other IT infrastructure elements. Access control, for example, is rarely built into specific apps or platform systems, because it is far more efficient and effective to centralize the development and management of that function at the infrastructure level. Be careful—this train of thought leads to apps that have zero secure function built into them, even the most trivial of input data validation!

Performance requirements, those analysts would say, are by nature functional requirements in this sense. The “-ilities”—the capabilities, availabilities, and reliabilities, all of the characteristics of the system stated in words that end in -ilities or -ility—are (they say) nonfunctional requirements.

As an SSCP, you'll probably not be asked to adjudicate this functional-vs.-non argument. You may, however, have the opportunity to take statements from the users about what they need the system to do, and how they need to see it done, and see where CIANA+PS-related concerns need to be assessed, analyzed, designed, built, tested, and then put to use. Monitored, too, of course; no sense building something if you do not keep an eye on how it's being used and how well it's working.

---

We live and work in a highly imperfect world, of course; it's almost a certainty that a number of CIANA+PS-driven functional and nonfunctional requirements did not get captured in the high-level systems requirements documentation. Even if they did, chances are good that not all of them were properly implemented in the right subsystems, elements, or components of the overall application system. The two-view look as described earlier (from requirements downward, and from on-the-floor operational use upward) should help SSCPs make their working list of possible vulnerabilities.

Possible vulnerabilities, we caution. These are places to start a more in-depth investigation; these are things to ask others on the IT staff or information security team about. Maybe you'll be pleasantly surprised and find that many of them are already on the known vulnerabilities or issues watch lists, with resolution plans in the work.

But maybe not.

Positive and Negative Models for Software Security

Ancient concepts of law, safety, and governance give us the idea that there are two ways to control the behavior of complex systems. Positive control, or allowed listing, lists by name those behaviors that are allowed, and thus everything else is prohibited. Negative control, or blocked listing, lists by name those behaviors that are prohibited, and thus everything else is allowed. (These are sometimes referred to as German and English common law, respectively.)

Antivirus or antimalware tools demonstrate both of these approaches to systems security. Software allowed listing, port forwarding rules, or parameters in machine learning behavioral monitoring systems all aim to let previously identified and authorized software be run or installed, connections be established, or other network or system behavior be considered as “normal” and hence authorized. Malware signature recognition and (again) machine learning behavioral monitoring systems look for things known to be harmful to the system or similar enough to known malware that additional human authorization steps must be taken to allow the activity to continue.

A quick look at some numbers suggest why each model has its place. It's been estimated that in 2018, over a million new pieces of malware were created every month “in the wild.” As of this writing, AV-TEST GmbH notes on its website that it observes and categorizes over 350,000 new malicious or potentially unwanted programs (PUPs) or applications (PUAs) every day, with a current total exceeding 875 million species. Although many are simple variations on exploits already in use, that's a lot of new signatures to keep track of! By contrast, a typical medium to large-sized corporation might have to deal with authenticating from 1,000 to 10,000 new applications, or new versions of applications, that it considers authenticated to be used on its systems and endpoints.

Positive control models, if properly implemented, can also be a major component of managing system and applications updates. The details of this are beyond the scope of this book and won't be covered on the SSCP exam itself. That said, using an allowed listing system as part of how your organization manages all of its endpoints, all of its servers, and all of its devices in between can have several key advantages:

• As new versions of apps (or new apps) are authorized for use, a “push” of the approved allowed list to all devices can help ensure that old versions can no longer run without intervention or authorization.
• While new versions of apps are still being tested (for compatibility with existing systems or for operability considerations), the IT managers can prevent the inadvertent update of endpoints or servers.
• Individual users and departments may have legitimate business needs for unique software, not used by others in the company; allowed listing systems can keep this under control, down to the by-name individual who is requesting exceptions or overriding (or attempting to override) the allowed listing system.
• Allowed listing can be an active part of separation of duties and functions, preventing the execution of otherwise authorized apps by otherwise authorized users when not accessing the system from the proper set of endpoints.
• Allowed listing can be an active part in license and seat management if a particular app is licensed only to a fixed number of users.

Is Negative Control Dead? Or Dying?

SSCPs ought to ask this about every aspect of information systems security. Both blocked and allowed listing (negative and positive) security control models have their place in access control, identity management, network connectivity, and traffic routing and control, as well as with operating systems and application software installation, update, and use. Crowdsourcing for data (such as crowd-science approaches like Zooniverse) are impractical to operate if all users and data they provide must be subject to allowed listing, for example.

Let's narrow down the question for now to application software only. NIST and many other authorities and pundits argue that a positive control model (allowed listing) is the best (if not the only sensible) approach when dealing with highly secure environments. These environments are characterized by the willingness to spend money, time, and effort in having strong, positive configuration management and control of all aspects of their systems. User-written code, for example, just isn't allowed in such environments, and attempts to introduce it can get its user-as-creator fired (or even prosecuted!). Positive control in this fashion is trust-centric—in order for allowed listing to work, you have to trust your software logistics, support, and supply chain to provide you with software that meets or exceeds both your performance requirements and your information security needs across the lifecycle of that software's use in your organization. Making allowed listing for software control work requires administrative effort; the amount of effort is strongly related to the number of applications programs you need to allow, the frequency of their updates, and the numbers of systems (servers, endpoints, or both) that need to be under positive control.

Blocked listing (or negative control) is of course threat-centric. It's been the bedrock of antimalware and antivirus software and hybrid solutions for decades. It relies on being able to define or describe the behavior signatures or other aspects of potentially harmful software. If a behavior, a digital signature, a file's hash, or other parameters aren't on the blocked list, the potential threat wins access to your system. The administrative burden here is shifted to the threat monitoring and intelligence community that supports the blocked list system vendor (that is, we transfer part of this risk to the antimalware provider, rather than address it ourselves locally).

Allowed listing (or positive control) is sometimes described as requiring a strong authoritarian culture and mindset in the organization; it's argued that if users feel that they have an “inalienable right” to load and use any software that they want to, any time, then allowed listing stands in the way of them getting their job done. Yet blocked listing approaches work well (so far) when one central clearinghouse (such as an antimalware provider) can push signature updates out to thousands if not millions of systems, almost all of them running different mixes of operating systems, applications, vendor-supplied updates and security patches, and locally grown code.

Software development shops probably need isolated workbench or lab systems on which their ongoing development software can evolve without the administrative burdens of an allowed listing system. (Containerized virtual machines are probably safer and easier to administer and control for such purposes.) Academic or white-hat hacking environments may also need to operate in an allowed, blocked, or no-list manner, depending on the task at hand. Ideally, other risk mitigation and control strategies can keep anything harmful in such labs from escaping (or being exfiltrated) out into the wild.

While the death certificate for negative control hasn't been signed yet, there does seem to be a strong trend in the marketplace. Until it is, and until all of the legacy systems that use blocked listing approaches are retired from the field, SSCPs will still need to understand how they work and be able to appreciate when they still might be the right choice for a specific set of information risk mitigation and control needs.

Application Vulnerabilities

If we apply some old-fashioned wisdom to the art of writing software, there are some right ways to produce good, clean, secure, safe, and resilient apps—and then there are any number of just plain wrong ways to do that job. Those “right ways” can lead us to developing and maintaining software in reliable, repeatable ways; our programmer/analyst teams build on experience with each new app. At the same time, our IT security team gains experience with threat analysis and risk reduction throughout this regular, well-defined, controlled, repeatable, and managed development, deployment, and support lifecycle. Quality managers talk about such end-to-end sets of business processes as capabilities—the business or organization can do that set of tasks, end to end. Mature capabilities are those that are repeatable and that are continually monitored so that the business learns from mistakes and from successes; such mature capabilities will more likely produce higher-quality outputs (such as apps that they write) more often than less mature processes can do.

Note that there are no guarantees here! The “wrong ways” can be struck by blind luck and produce an application that works right and is reliable, robust, safe, and secure, perhaps just because some members of the team knew how to do things better. Similarly, very mature processes can still make mistakes.

Remember, software doesn't wear out; a set of instructions to ask the user for data, check it against constraints, and then send that data to the backend database server will not start to fade away, dropping out instructions or steps. The hardware it runs on might break down, but it's safe to say that all software vulnerabilities are human-induced.

Let's say that a different way: failures in the lifecycle process to specify, design, code, build, test, and use the software properly allow mistakes to go unnoticed—and some of those mistakes may result in exploitable vulnerabilities!

As you saw in Chapter 4, “Operationalizing Risk Mitigation,” vulnerability assessment tells us that the larger and more complex the system, the greater the likelihood that it will contain more exploitable vulnerabilities. And as you saw in Chapter 8, “Hardware and Systems Security,” unmanaged systems have a far greater likelihood that vulnerabilities will be found and exploited by attackers than do well-managed, well-controlled systems.

Vulnerabilities Across the Lifecycle

As with systems software, applications are vulnerable across their lifecycle. For example, during development, several main threat vectors exist:

• The host operating system, network hardware and software, and other infrastructure elements may contain exploitable vulnerabilities that allow for exfiltration or infiltration of code and data, surreptitious monitoring of development activity, or other potentially harmful and unauthorized accesses to systems resources.
• The IDE software, other programming tools, test tools, library managers, and configuration management and control tools can have exploitable vulnerabilities in them, which can be used to “poison” or infect the ongoing development effort with malicious code fragments, as well as being used to exfiltrate sensitive design information about the project.
• All of the ideas, code, and documentation generated by the developers could be exploited by attackers to find vulnerabilities being built into the system (as if by accident). Requirements documents, design information, source code, test data and drivers, builds and controls scripts, development and test logs, and progress reports all contain valuable insight into both the team's processes and the product they are building.
• Development environments are also susceptible to attack. Insecure IDEs or the network or cloud-based library systems that they use are prime targets for infiltration, the insertion of hostile code and data fragments by attackers into the system being developed. (Such Trojan horse attacks during development have long been plot elements of cyber-fiction and espionage novels, which draw their inspiration from the demonstrated value of having insiders surreptitiously sneak in a few lines of hostile code here, substitute an entire module there,…)

During initial deployment, and later with redeployment of new versions, updates, or patches for the finished, tested, and trusted app, other potential weaknesses in process control and management could lead to any number of exploitable situations:

• Application software deployed as installation kits can be vulnerable to substitution of component files by a threat actor; allowed listing systems may not be able to check every component of a major application platform.
• During use, data input provided by users, over the Internet, or via databases or data files could drive the app to execute abnormally, which could expose system resources to further exploitation, malicious code being installed and executed, and so forth.
• Databases or data files used by the app, if not properly secured, can be hacked in ways that allow transactions to execute as if authorized and normal but in unauthorized and harmful ways. For example, hacking the payroll database to include a fictitious employee, complete with direct deposit information, can siphon off money from the company every pay period, and yet the payroll system itself may not be able to detect this “ghost employee.”
• Data can be exfiltrated from the files or databases used by the app.

In general, it's hard for attackers to exploit these kinds of vulnerabilities in an app's source code, executable files, control parameters, or data files without some other failure of security:

• Failure of access control and identity authentication and authorization systems opening the door for the attacker
• Failure by the application logic itself to properly validate that user-supplied data is correct, consistent, and authorized
• Failure by the application logic itself to recognize out-of-limits conditions, or anomalous or unauthorized actions being requested, and safely abort those operations or shut down in graceful ways

In all of these cases, failure to notify information security and IT personnel of the potential violation of security just compounds the chain of violations. As does failure by the information security team to be monitoring, logging, and analyzing the results of all of that monitoring!

Human Failures and Frailties

As with every information risk mitigation and control strategy, tactic, and operation, keeping applications programs free from deliberately or accidentally introduced vulnerabilities depends on the human elements in the organization's software development processes. Social engineering attacks may try to find a development team member, an administrator, or a file clerk who can be “turned” or subverted to the attacker's wishes. Whether through momentary bursts of incompetence or sustained and growing hostility toward the project, the company, or their teammates, the risks presented by the human element cannot be ignored.

Phishing attacks continue to proliferate and become more varied and sophisticated; as of December 2018, the latest variation on this theme, the “catfish” (or bottom-feeder) attack pattern, tries to develop a long-term relationship with staff members within the target organization. They may pose as a prospective vendor or customer, an educator, even a prospective employee! Over time, the attacker's e-credibility increases, and the target staff member's resistance crumbles. Such attacks can gather significant information about the software (applications and systems) being used at the target company, how tightly it is controlled, and how well it is maintained. Offering a sympathetic ear to complaints about the systems being used, attackers can spot potential vulnerabilities—either in those systems or with other humans in the organization to target with social engineering efforts.

Let's face it: people need to trust one another; we need to be able to bring the stranger in from beyond the pale and make them a member of our circles of acquaintances, friends, marketplaces, and tribes. This is why criminal law refers to the scam artist or the social engineer as a confidence artist, as one who plays on our needs for trust and confidence so as to deceive and exploit us. We defeat or deter such con men (and women, of course!) by bestowing our trust only when it is earned, rather than granting it blindly; this is nothing more than due care and due diligence require. Helping our organization achieve and maintain this kind of security posture takes training, teaching, and leading by example—all of which you can start delivering on your first day on the job.

“Shadow IT:” The Dilemma of the User as Builder

Beware the end user! Armed with spreadsheet macros and formulas, end users can extract data from configuration-managed corporate databases, apply their own code and data magic, and produce decision-influencing answers that management and leadership depend on. Another user might build email-enabled and highly automated process flows, using some of the other features in the company's productivity suite. Still other users might be absolute wizards at organizing critical information, documents, spreadsheets, and information repositories in the company's shared storage resources. Using business intelligence analytical tools, another power user can build management and leadership just the decision support dashboards they want, when they want them. And all of these end users are doing this creative problem-solving work totally outside of the IT department's configuration management, builds and control, or quality management systems. Information security gurus in the company may not know any of these apps exist. Even the chief information officer (CIO) may appreciate the praise of other senior leaders for providing an IT infrastructure and tool set that lets people be so much more productive without even knowing that much of that productivity depends on “hobby shop” logic embedded in an uncontrolled, undocumented, and unmaintainable morass of files and file types.

Shadow IT, as you saw in Chapter 4, is the name for this “under the radar” set of people, products, and services that extract, create, gather, massage, and combine data to produce a whole set of answers to many different questions. Shadow IT is any process, business logic, or human procedure that is implemented in software, data, metadata, or other IT elements in ways that are outside of the normal processes the organization uses to manage the development, use, support, and security of its IT systems, infrastructures, data, and applications. Tom, for example, may be a wizard when it comes to setting up spreadsheet formulas; his department manager and others use his spreadsheets to extract data from the corporate database system on a regular basis. Nobody really understands how Tom's spreadsheets work, but they've used them for years, and they rely on them. Then Tom gets hit by a Powerball, winning a life-changing annuity from the state lottery, and retires. Now what happens? Who will maintain these spreadsheets?

Why does shadow IT exist in the first place? Simply put, far too many organizations, managers, and workers believe that the managed and controlled IT development process, with its multistep SDLC, takes too long and costs too much to get a quick and simple answer to a right-now need. They believe that the power and versatility of modern IT applications make these same-day solutions easy, safe, secure, and reliable. As a result, the balance between reliability and right-now gets upset.

Software vendors have worked hard to provide greater capabilities that enable the end user to create, manage, process, route, and control the way information is used within their office, their team, their company, or even with outside business associates. In the last few years, the reach and power of such “end-user-empowerment solutions” has grown almost tenfold.

---

Why Is This Bad News?

It all comes down to whether the individual end users are skilled and experienced at designing, building, and maintaining IT systems that are safe to use, reliably produce correct answers, and protect the organization against misuse, bad data as input, or other hazards. It comes down to whether they have built and can maintain these self-created tools to meet or exceed the CIANA+PS needs of the organization. If they can, great! Bring these people in from out in the cold of the shadows and recognize and reward them, for the survival of your business depends on them more than you might know.

If they cannot…in one IT manager's epithet, they are loose cannons looking for a ship to sink. They could potentially sink the business.

---

It is unfortunately true that throughout the history of computing, we have struggled with how to set this balance. SSCPs probably cannot influence how their organization sets this balance (and it may even be career limiting to try!). SSCPs can, however, work with others in the organization to gain a better understanding of the scope and severity of the information risks posed by shadow IT.

Shadow IT can take many forms:

• Application programs written in almost any programming language (even ones not supported by the organization's software development infrastructure)
• HTML, CSS, Java and JavaScript, or other web page elements
• Stored query procedures that users can create and then use with the company's formally supported database systems
• Batch files, shell scripts, or other procedures that users can create with a text editor and then run via the command line interpreter
• Visual Basic, self-recorded macros, or other procedural scripts generated by word processors, spreadsheets, presentation programs, email clients, etc.
• Process flows defined for email and attachments that interact with mainline company information systems
• Formula in spreadsheets (or in other documents) that check for conditions and then branch to process, present, or save data in particular ways
• Conditional logic for auto-repeating tasks, event schedules, and the emails that tie them together

Allowed listing is probably not going to help us here. In almost all cases, the shadow IT elements are loaded and executed by allowed listed programs (such as Microsoft Excel, PeopleSoft, or Quicken for Business). Those programs can be locked down to prevent all but a trusted set of macros, metadata, or other procedural information from being loaded and executed, but many organizations find this administratively difficult to manage. It's also very hard to get users and their managers to support “turning off all of the macros,” for example. Except in the most security-conscious of organizations, too many users at too many levels in the chain of command have come to depend on their own quick and dirty shadow IT tools to solve today's problems today.

Data and Metadata as Procedural Knowledge

In many organizations, data and metadata play both a formal and informal role. Strong data modeling and data quality processes may implement business logic that defines the right ways to gather new data, create new data, input it, change it, output it, and retire it. In other places—even in the same organization!—you could find significant amounts of data and metadata that is not managed and not subject to change control, auditing, or data quality measures.

First, let's look at data and metadata as procedural in nature, as information that tells the organization what to do and how to do it. Recall that we previously defined procedures as administrative, human-facing information products that provide the step-by-step instructions, constraints, and exception handling rules for portions of the organization's business logic. We also defined data as the values or fields that describe, model, or represent some aspect of a real entity, whereas metadata is data that describes, limits, or establishes constraints about data itself. For example, an accounts payable system might have data fields about a bank account, which would be the ACH routing number, SWIFT code, account number, account holder's name, bank name, and the like. Metadata might define that for banks located in certain countries (which don't use ACH routing), the account must have both SWIFT and IBAN bank routing codes, or the account cannot be used for payments or debits.

---

Dealing with Domain-Specific Procedural Knowledge

Terms like SWIFT, ACH, IBAN, and others may dominate your thinking if you're involved with international funds transfers for personal or business reasons. They illustrate how just the acronyms as names themselves are the tip of a knowledge and insight pyramid, for people working in that field. These names are metadata specific to a particular business domain or activity; they embody the larger business or marketplace rules for such funds transfers, while associating that “how-to” knowledge and rule sets with specific data items or records in an individual transaction.

As an SSCP, you'll quickly find that the business or marketplaces your employer is in will dictate any number of such sets of metadata names. The better you know the language of your employer's business, the better you can help keep its information systems safe, secure, resilient, and reliable.

---

Data dictionaries provide centralized repositories for such business rules, and in well-managed applications development and support environments, the organization works hard to ensure that the rules in the metadata in the data dictionary are built into the logic of the application used by the business.

Without a data dictionary as a driving force in the IT infrastructure, the organization resorts to old-fashioned people-facing procedures to capture those business logic rules. That procedural knowledge might be part of initial onboarding and training of employees; it might only exist in the user manual for a particular application, or the desk-side “cheat sheet” used by an individual worker.

Think about that banking example again: metadata established a rule about when we needed more information about a bank in another country, but the list of specific countries was data, not metadata.

All organizations face a dilemma when it comes to procedural knowledge. The smarter your people at the gemba are, the more that they know about their job and the more they understand the meaning of the data that they retrieve, use, create, receive, and process, the greater their ability to protect your organization when something surprising or abnormal happens. But the more we depend on smart and savvy people, the more likely it is that we do not understand all of our own business logic.

What can happen when that procedural metadata is not kept sufficiently secure? Loss or corruption of this procedural and business logic knowledge could cause critical business processes to fail to work correctly. At best, this might mean missed business opportunities (similar to suffering a denial of services [DoS] attack); at worst, this could lead to death or injury to staff, customers, or bystanders, damage to property, and expenses and exposure to liability that could kill the business.

What can the SSCP do? In most cases, the SSCP is not, after all, a knowledge manager or a business process engineer by training and experience. In organizations where a lot of the business logic and procedural knowledge exists in personal notebooks, yellow stickies on physical desktops, or human experience and memory, the SSCP can help reduce information risk and decision risk by letting the business impact analysis (BIA) and the vulnerability assessment provide guidance and direction. Management and leadership need to set the priorities—which processes, outcomes, or assets need the most security attention and risk management, and which can wait for another day. And when the SSCP is assessing those high-priority processes and finds evidence that much of the business logic is in tacit form, inside the heads of the staff, or in soft, unmanageable, and unprotected paper notes and crib sheets, that ought to signal an area for process and security improvement.

But what about data as just data, information that models, describes, or represents people, employees, customers, inventory items, bills to pay, and the myriad other kinds of business objects organizations deal with every day? Bad data, as we saw earlier, can cause applications to malfunction, crash, or worse! How do we avoid those fates?

Information Quality and Information Assurance

Think back to the relationship between information assurance and decision assurance, as we defined it in Chapter 3. Nobody gathers information just for the sake of gathering more information; whether today or years from now, they gather that information because they know it will help them make a better decision about something that matters to them! We also saw then that without taking steps to verify the quality of the data going into that decision, the rightness, the utility, and the value of that decision to us is suspect.

This is the “garbage in, garbage out” part of computing. Bad information in leads to waste, lost time and effort, and lost opportunity. Sometimes it leads to lost lives! (Think what happens if a hospital orders up two units of blood typed and cross-matched for the wrong patient, or an air traffic controller says “descend” when he really meant “climb” to avoid a possible midair collision.)

Thus, to make quality decisions—ones we can “bet our business on”—we need to ensure that we have sound business logic that uses quality information to come to those decisions.

---

What Is “Information Quality?”

According to Larry English, author of Information Quality Applied and other books and articles on this subject, information quality for your organization is:

• Consistently meeting or exceeding all knowledge workers' and customers' expectations with information…
• So that knowledge workers can perform their work effectively and contribute to the enterprise mission…
• And so that customers are successful in conducting business with you, and are delighted with the products, services, and communications (or information) they receive from you.

English goes further, stating that the three key aspects of providing end-to-end or total information quality management must include:

• Specifying the data definition, valid business rules for use, formats, valid value sets or ranges, and the details it takes to implement such data with quality in database systems
• Information content quality
• Information presentation quality

How serious is the information quality problem? English, in 2009, cited sources showing that over 122 organizations suffered losses of over $1.2 trillion because of bad data. They lost customers; they wasted resources and labor; they redid work; in some cases, they went out of business. By 2016, IBM reported (in the Harvard Business Review) that this “garbage-in” impact had grown to $3.1 trillion. Nearly three times the growth in bad data losses in 7 years.

That's not loss and damage done by hackers. That's not losses due to data breach. That's self-inflicted wounds bleeding out.

---

Information Quality Lifecycle

Like everything else, information has a lifecycle within an organization. This lifecycle starts with the business logic: why do we need the data, and what are we going to do with it? This logic should specify the kind of rules, constraints, or quality parameters that we need to ensure that good, useful, and complete information comes into our systems and bad information is rejected or routed to special procedures that may be able to clean, correct, or bridge over the faults in the original and make it useful to us again. We then store the information, use it in business processes, modify it, store it, display it, share it…

At some point in time, the information is no longer of value to the organization, and it needs to be disposed of. Again, our business logic ought to dictate whether such information can be sold or must be destroyed. Note, too, that legal and regulatory requirements may apply to how and when we must dispose of information and that failing to dispose of data that is past its legal limit can expose the company to legal liabilities.

Along the way, we keep backup copies of the information, typically in both snapshot sets that represent a moment in time and in full archival copies of our entire systems. These backups are a vital part of our business continuity and disaster recovery planning, which you'll learn more about in Chapter 11, “Business Continuity via Information Security and People Power.”

Preventing (or Limiting) the “Garbage In” Problem

As an SSCP, you might think you don't have much of a role to play in helping your organization limit the impact of “garbage in.” Or do you? In many respects, there's a lot of similarity to how your role on the information security team can help the business grow and use higher-quality applications software. Get your best friends—Kipling's six wise men—and be prepared to ask a few questions to start your polite inquiries:

• Do we have a formal information quality program?
• Do we have and use a formal data dictionary or data model? How do we ensure that application programmers and business process owners and operators live and work by the business logic rules in that data dictionary or data model?
• Is our data dictionary or data model under formal configuration management and change control?
• Do we know how and when bad data impacts our business processes?

With those answers to start with, you're in a better position to talk with the knowledge workers who use those business processes as part of their jobs and ask them questions like these:

• How do you recognize bad input data, such as from customers, outside organizations, or other parts of our business, when you encounter it?
• How do you recognize bad output data when the system displays it to you?
• In either case, do you have formal, approved processes to handle these exceptions? Or do you have to just use your own best judgment?

---

Be Careful Asking “Why”

As one of Kipling's six wise men, why is a powerful but two-edged sword.

Almost every answer to a “why” starts with “because,” which can mean either “here's the cause” or “here's my judgment on that.” You might want to save your whys for when you need to understand (and even challenge) motives and decisions, and use hows to look at cause and effect.

---

Much as we saw with the business process logic itself, with these answers in one hand, and the BIA and vulnerability assessment in the other, the SSCP can start to determine if there are data-driven exploitable vulnerabilities at the endpoints.

Remember, attackers can cause your business to go out of business by attacking the quality of the data your coworkers use to make decisions and carry out their assigned work. They don't even need to exfiltrate the data to do so.

That said, let's also consider how to protect the data (and metadata) from the effects of a vulnerability somewhere else in the systems being exploited against your organization.

Protecting Data in Motion, in Use, and at Rest

This is the other critical part of keeping your information systems safe, secure, resilient; this is where you've got to know all of your CIANA+PS requirements and have active, designed-in, and purposeful processes that deliver on those requirements. You then have to do the vulnerability assessment to see where your best-laid implementation plans got it wrong!

Two forms of attacks on data need to be kept in mind as we think about protecting our data. The first are data breaches, those attacks that attempt to view, use, or copy the data for use by the attackers, once they have it outside of our span of control. But the other, more pernicious type of attack is a malformed input attack: these are attempts to misuse data as inputs to our applications, systems, processes, and business logic, as part of attempts to sabotage, divert, or fraudulently exploit those processes. Both of these are data-centric attacks; and it takes a somewhat different perspective for our threat modeling, vulnerability hunting, and security analysis to focus on the data first, rather than on the processes and systems that create it and use it. Recent publications such as NIST's SP 800-154, Guide to Data-Centric System Threat Modeling, offer some approaches that can help in this regard.

To help us do this shift in perspective, we might want to extend this three-part (motion-use-rest) data security model a bit and add a few other steps in the data or information lifecycle into our thinking:

• Data modeling, definition, and metadata creation to assure information quality needs
• Input or acquisition of data from outside of the organization's quality span of control
• Data in motion to and from internal storage (or rest) facilities
• Data copied in backup sets, in archive sets, or to redundant and dispersed systems elements (for enhanced availability, or for business continuity and disaster recovery purposes)
• Data at rest in primary systems storage locations (datacenter, cloud storage, local hard drive, etc.), awaiting use
• Data at rest in primary systems storage locations, awaiting destruction
• Data in motion to and from endpoint devices, for use by users (or endpoint devices, such as robots and controls) via applications
• Data in RAM on servers, endpoints, or other devices
• Data retrieved from any system (primary or backup) to be delivered to attorneys, government officials, etc. as part of a digital discovery process
• Data on an endpoint or other device that has become lost, stolen, or misplaced, or that has been disposed of without properly being zeroized or randomized to destroy the data
• Data at rest on backup media, or in backup storage locations, that needs to be destroyed (expired, no longer fit for purpose, or to meet legal, contractual, or regulatory requirements)
• Data and information in tacit form, in the minds of employees, customers, vendors, or others
• Data that has been output from the systems (via some endpoint) and transformed into a printed or other format that can escape our security and control processes
• Data being displayed to an authorized user but observable by an unauthorized person or persons
• Data at the end of its useful life or retention span, which must be securely destroyed or disposed of

---

What about the Storage Devices the Data Is On?

We also have to shift our mental gears here and think not about the data but the devices that the data are stored on. Prior to the cloud, we stored all of our data on hard drives, tapes, floppy disks, disk cartridges, or even paper or punched cards; we controlled who could have access to those physical media, and (if we were practicing due diligence) we destroyed that media when it wore out or the data on it needed to be destroyed.

Moving our data into the cloud means that our data shares living space on the cloud provider's disk farm with data from many other users. If just one of those users is served with a subpoena, a national security letter (NSL), or a digital discovery order, or a search warrant seeks all of that user's data, your data that shares living space with that user's data get delivered to the requesting court or agency.

Your data can also “leak out” of the cloud if a malfunctioning disk drive is removed and thrown away without being zeroized or clobbered properly. This data remanence problem exists not just with cryptographic devices, but with many hardware (and software) systems that retain input data, the intermediate processing results they generate, or diagnostic data. (This begs the question of which of your temporary files need to be securely randomized instead of just erased.)

Most cloud providers deal with these risks with a combination of striping of files and directories across multiple physical devices and encrypting each customer's data separately before storing it. That said, as an SSCP, you need to check your service level agreement or terms of reference with your provider.

---

Every one of those steps in the life of a set of data needs to be thought of in CIANA+PS risk terms. Are we at risk, for example, if data we think we ordered to be destroyed has actually not been destroyed yet? (Probably.)

By this point, SSCPs should recognize that almost every tool in their information security tool kit needs to be employed in a systematic, integrated way to achieve the CIANA+PS needs of the data and information that is the lifeblood of the organization. This means the full range of physical, logical, and administrative controls are applied when, where, and how the risk assessment and vulnerabilities assessment indicate the greatest risks are. For example:

• Frequent and timely audit of identity management, access control, and applications logs should indicate that attempts to circumvent these controls have kept attackers out of the data itself, and the data hasn't been moved, copied, or otherwise exfiltrated.
• Physical and administrative controls, including audits and inspections, should verify that backup copies of information (and systems and application software) have been kept safe from attack or compromise.
• All of our people are educated on the job-killing risks of improper use of thumb drives, attachments to emails, personal cloud storage, or “bring-your-own-infrastructure” storage, and have been trained to properly use (or not use!) such capabilities as our policies and CIANA+PS needs dictate.

This suggests that (like so many things in information security), our most powerful lines of defense can start with:

• Physical protection of the information systems, communications, and endpoints
• Identity management, identity provisioning, access control, and privilege management
• Integration of administrative (people-facing) policies and procedures with software and systems implementations of policies, controls, alarms, logs, and the systems, apps, and data themselves
• Ongoing and effective monitoring, inspection, and assessment
• Incident detection, characterization, and response
• Disaster recovery planning and business continuity measures, planned, in place, rehearsed, and evaluated

Data Exfiltration I: The Traditional Threat

Most computer crime statutes define as theft the unauthorized removal or copying of data from someone's information system. Although that legally defines the crime, the IT security industry has been calling this data exfiltration. This threat has existed probably as long as people have been writing information down in any form.

Before an organization moves any portion of its business logic into the clouds, it is still faced with the significant risk of data exfiltration—data moving outside of the organization's span of control (and its threat surfaces), and “into the wild” for use by almost anyone for almost any purpose. This “traditional” exfiltration threat could involve the unauthorized movement of data via:

• Outbound (and draft) email content or attachments
• Downloads or file copies to poorly secured, insecure, or unauthorized devices (which could be thumb drives, laptops, smartphones, diskettes, or even paper print-outs)
• Tacit knowledge exfiltration, where the data or knowledge is read, heard, or seen by a person who then shares that data with other unauthorized parties or uses it themselves for unauthorized purposes
• Upload or transfer to unauthorized file sharing, storage, processing, or other services
• Downloading or transfer of data to secured or trusted devices, which are then removed from the workplace for data extraction to occur elsewhere
• Extraction of data from disposed hardware, particularly disk drives

Clearly, identity management (of people, processes, and devices) can control some of these classes of exploitation risk events. Access control also has a powerful role to play.

Preventing data loss must start with data classification and categorization; nothing else makes sense. Recall from Chapter 4 that the security baseline has (or should have!) identified the possible impacts of the loss of each type of information asset. This should (with emphasis on the imperative) drive the organization to establishing controls. Each of the exfiltration examples above exploits a hole in the organization's threat surfaces; they show us untrustworthy paths which need to be identified, controlled, and monitored. Each suggests that a positive security model could be used to identify the legitimate, allowable ways in which such data can move across these paths (if at all), with all other attempts to do so being unauthorized by definition.

With that security baseline firmly in hand, the next step in applying our risk management model is making a strategic choice: deter, detect, prevent, and avoid. Deterrence and prevention go hand-in-hand with having a solid access control and identity management system in place; the visible presence of a monitoring and surveillance activity can also deter the would-be data thief. But what about detection?

In recent years, data exfiltration attacks have taken on a pattern that looks at five major stages to an attack:

• Stage 1: Reconnaissance
• Stage 2: Initial compromise and entry (typically involving phishing attacks)
• Stage 3: Establish command and control
• Stage 4: Identify, select, acquire, and aggregate data
• Stage 5: Exfiltrate data

(Some attacks do demonstrate a sixth stage, in which the attacker erases all evidence of their presence, including their command and control hooks, and then departs the scene.)

We've examined how to detect events of interest in those first three stages in other chapters. Stage 5, the actual exfiltration (or criminal export) of the data, presents unique challenges, since most such attacks take steps to actively obscure or mask the data being exfiltrated. Breaking the data up into packets, encrypting the packets, combining packets from multiple sources within the target, and spoofing the file types to attempt to have the data masquerade as some other kind of data stream are just some of the techniques that the data thieves use to let the outbound flow of data look normal. Even a simple screenshot of classified data may easily sneak past any filters set up to detect and block the exfiltration of that data in its normal form. All of these techniques aim to remove or mask data classification labels or tell-tale patterns in the data, and even remove, suppress, or alter digital signatures. Scheduling the flow of data so that it hides within other routine outbound flows can also minimize the chances of detecting the ongoing exfiltration.

So we have to focus on Stage 4 of this data exfiltration model if we are to gain any traction in detecting such thefts before the data leaves our premises.

Detecting Unauthorized Data Acquisition

Imagine for a moment that as an SSCP, you're working in an extremely security-conscious environment. Every bit of useful information is kept in a locked, guarded library; every access to that library requires proof of identity, need to know, and validation of your stated purpose. The librarians are selected and trained to trust no one. Everything you do with that data is monitored, as if “Big Brother” were shoulder-surfing with you every moment you are at work. Your task complete, you return what you checked out from the library, and you place into the library the new work products you created in part from that information; you also enter into that library all of your loose notes, even the sketches on the back of a paper napkin, that in any way relate to that highly classified information.

The history of espionage and counter-espionage tells us that such systems will work only until they fail; somebody will defeat them. In the meantime, the audit trail of who asked for what information, why, for what purpose, and what did they actually do with it, is a powerful set of telemetry data about the movement of data, information, and even knowledge within our organization. This telemetry also can provide a warning if someone is requesting information in ways that suggest they are trying to put too many pieces together, pieces that need to be kept secret and safe.

Move that highly protected, human-operated library out of the spy thrillers and into a typical corporate IT infrastructure, its apps, and its business logic. Identity management and access control systems can indeed generate that telemetry data. The more information that we need to watch over so closely, the more system resources (CPU time, network traffic, and storage) are required to generate and maintain the telemetry logs.

Here's the rub: as in the fictional settings of a John le Carré novel, the real world of major national intelligence agencies or in modern IT-enabled organizations, we may have all of that log data but we can't make sense of it. We don't have the analytical capabilities to read all of those logs, search for patterns, and correlate those patterns to see if they're telling us that the copying, gathering, and clumping up of data that's going on is in fact an ongoing exfiltration attempt. For example, monitoring outbound email or Web traffic may help a small organization detect a change in the pattern of sending and receiving addresses, which might be a signal of something suspicious. A company with tens of thousands of employees may not find this practical or achievable.

Security systems vendors offer a variety of security event information management and analysis capabilities, many of which host a variety of machine learning functions that promise to solve this “drowning in log data” problem. As with any alarm system, they will produce both false positives and false negatives. The false negatives mean that data exfiltration escaped detection (and prevention). False positives can overload your investigative staff and even erode the moral support from end users and their managers that all information security is so depending on to be successful. Most SIEM systems and managed security services platforms now use a wide variety of machine learning techniques to perform behavioral analysis, pattern recognition, and automatic signature generation. Even so, false positives and false negatives will still be a problem, and the lag between a change in user and system behaviors and the learning system's being able to meaningfully discriminate acceptable from suspicious can be substantial.

Preventing Data Loss

At some point on its journey to an improved security posture, any organization will have to start planning, prioritizing, and implementing data loss prevention, detection, response, and recovery measures. Preventing the loss (and therefore compromise) of data can come about through a wide variety of circumstances:

• Work-from-home situations may expose data while in use, in motion (to or from the in-home work area), and at rest on local storage or in paper form. Most multifunction printers, routers, and other IT systems can be configured to provide better security, but these are often overlooked by their users and their organizations.
• Accidental disclosure often occurs through incorrect inclusion of sensitive data into reports, web pages, press releases, or datasets shared with partner organizations or clients.
• IoT, other OT subsystems, mobile devices, and their access points can all leak data if not actively secured.

Most of the emphasis in the security services marketplace seems to be on securing personal sensitive data, and this is good; it's being supportive and responsive of data protection laws and compliance requirements. But a data breach that compromises sensitive plans, intellectual property not yet protected by patents or other legal means, or the data supporting cutting-edge research can be even more devastating to the organization, and thus to its stakeholders' interests.

These plans will often address three broad categories of approaches: cybersecurity hygiene measures, content-focused measures, and activity-focused measures.

Cybersecurity Hygiene for Data Loss Prevention

These are the commonsense, reasonable, and prudent steps that systems owners and users should take to establish a reasonable security posture as a starting point. From a data loss perspective, organizations can take steps such as:

• Implement stronger, more pervasive identity management and access control processes.
• Control, restrict, and monitor the use of removable media, storage devices, and online or cloud-hosted data storage services.
• Use digital rights management (DRM), which encapsulates the protected files with encryption-based locks on owner-specified privileges.
• Encrypt data at rest, either by classification level or across all data assets in the organization.
• Data tagging implements data classification by binding security labels to sensitive datasets, records, or individual items. This requires controls to enforce tag checking and prevent tag removal (which would be a down-write in security modeling terms).
• Implement dynamic digital watermarking to mark all screenshots, file copies, and printed documents as a deterrent measure.

  ---

  Steganography as Watermarks

  Many copying machines, printers, and scanners use steganography to watermark each document copy they print or make, thus embedding information such as the date, time, and machine used to produce or process that copy. Such watermark information can be used for a variety of internal purposes, from process control and quality improvement to loss prevention. Consistently implemented, watermarking tactics can also provide evidence to support a forensics investigation after an information security incident has occurred. The watermarks and the controls for imposing them onto data should be managed as cryptologic assets.

  Such use of steganography is not constrained, of course, to copiers and scanners.

  ---

Content-Focused Data Loss Prevention

This is an information asset–centric process that starts with risk management and then performs data classification and categorization to create a security baseline. At this point, the marriage of what types of content need what kinds of control strategies, tactics, and operations can be put in place. This is essential to help balance cost, friction, and security.

Many data loss prevention (DLP) systems and services will use a variety of approaches to determine if a data security policy is potentially being violated. Sometimes called deep inspection, these approaches examine some or all of the data payload in messages or network traffic, using techniques such as:

• Rule-based inspection may use regular expressions, Boolean logic, or similar techniques to identify types of data, such as credit card numbers or contract numbers.
• Database fingerprinting looks at exact snapshots or copies of data records or substructures (such as a set of transaction records) from a database. Also known as exact data matching.
• Exact file matching does not analyze the content of the file; instead, it computes a file digest for the content in question and compares that to a database of restricted file digests.
• Partial document matching may be useful when multiple versions of a document need to be controlled, such as all instances of forms templates filled out by different users, customers, or applicants for services.
• Conceptual or lexicon approaches use dictionaries of restricted words, combined with regular expressions and rules, to scan suspect content for instances of violations.
• Machine learning techniques, such as statistical or Bayesian analysis, can in some cases detect when nonstandard encryption is being used to mask data being exfiltrated.
• Predefined patterns or categories are commonly used to identify common data fields in financial, health data, and other structured data.

Activity-Focused Data Loss Prevention

This type of data loss prevention technique looks to find patterns in the behaviors of entities within the system (which includes external entities that have access, authorized or not, to that system). For example, large-scale data exfiltration attacks will often fragment very large datasets into smaller segments of arbitrary and somewhat random length and then use multiple pathways to transmit these segments. Some may go as content steganographically embedded in otherwise innocuous image, video, or audio data; others might go as individually encrypted sets of data. This might spread the upload of a terabyte-sized database over a month or more. Detecting such an exfiltration in process might require making meaningful comparisons of systems behavior, network traffic, and user behavior over long periods of time, with a combination of UEBA-based access control, web applications firewalls, content management platforms, and data discovery tools.

Detecting and Preventing Malformed Data Attacks

Malformed data or malformed input attacks have long been used by software and systems testers; this is the common practice of driving the system or application under test with input streams of test data that attempts to determine how the system responds to out-of-limits inputs. A trivial example of this might be an online banking system's logic that detects user attempts to exceed limits on maximum online withdrawals (by number and amount) in a given time period.

Operationally, the attacker has two possible goals in mind when presenting bogus, out-of-limits, or other malformed inputs to a system or application: the first involves getting the system to execute commands of the attacker's choosing, while the second gets the system to perform normal business processing but on data of the attacker's choice. Let's take a closer look at these:

• Arbitrary command or code execution: Some types of software and systems vulnerabilities such as input data buffer overflows will cause the system to enter an incorrect mode of operation in which the attacker's inputs are interpreted as commands or directives to the system, rather than being processed as input data by the application or systems element under attack. Query injection attacks take advantage of these vulnerabilities when they allow the attacker to enter database queries or scripting language commands into data input fields (such as a username or a customer mailing address field on a form). Another form of this attack causes the target system to treat some or all of the attacker's data as if it were machine-language instructions, to be processed by the CPU.
• Spurious data processing attacks: Attacks such as email business compromises often involve an element of social engineering as well as more technically focused attack techniques. A bogus invoice, for example, sent as an email attachment to an organization's accounts payables department, may very well be accepted for routine payment if the amount it claims for payment is lower than a threshold requiring management approval. You might think that rudimentary checks and balances might detect that the purported vendor on the invoice hasn't been entered into and approved as one that can submit bills for payment; insider collusion may easily sidestep such controls, and poorly designed controls may actually facilitate such frauds by allowing a certain number of invoices to be accepted and paid, even if the new vendor identity is supposedly pending approval.

Malformed data attacks are quite commonplace. They have long been used by military and intelligence operations that attempt to spoof message traffic in an adversary's systems, or as part of signals-based attacks that attempt to confuse or directly sabotage the sensors and systems in weapons systems. Many ATMs and similar systems have been vulnerable to end-user attacks that attempt to flood their keyboard input processors; some ATM designs still in use today are more vulnerable to these when their network connections to their host are unreliable and prone to timeouts and errors. It's not clear when the first computer-based fraud using malformed data was perpetrated; what is clear is that businesses and organizations in the public sector are facing growing amounts of email-based and e-commerce enabled frauds and other attacks involving malformed data.

Detecting and preventing such attacks requires a multifaceted approach, one that includes all the techniques covered throughout this book. Errors in applications logic are inevitable, as are exploitable weaknesses in the human-powered processes our organizations use on a daily basis. Limit checks, separation of duties, and appropriate layers of dual or multiple control can help limit the damage in some cases. Larger enterprises are finding some advantage in extending the use of UEBA and endpoint detection and response tools to cover the behaviors of multiple, seemingly unrelated activities across multiple systems (or major elements of their architecture); this can sometimes detect anomalous patterns involving entities, activities, and data, that might be an attack in the works.

Into the Clouds: Endpoint App and Data Security Considerations

When a business or organization moves its information systems and business logic “into the clouds,” this typically refers to its choices of a mix of deployment models. Think back to the notional datacenter model that we examined in Chapter 8. What separates a datacenter from a cloud can be found in several key characteristics, all summed up in one word: virtual.

• Compute power, represented by the number of processors and the amount of RAM available to them, is finite in any case. In a datacenter, the only way to significantly expand computing capabilities is to lease or buy more CPUs, GPUs, and RAM, along with whatever it takes to interconnect them into the datacenter. Even if the datacenter supports the use of virtual machines, the business cannot double the number of VMs that can get work done per hour, for example, without investing in more hardware. And that takes time—time measured in weeks if not in months! Cloud systems, by contrast, in near real time can effectively expand the amount of real processor and memory resources available to a customer's VMs for the duration of that customer's demand. Quite often, this involves the minute-by-minute rental of VM support resources on other cloud centers the provider owns or has contractual service relationships with. Cloud-hosted systems can also quickly release these extra assets from use, again in near real time, as business needs shrink throughout the day or the season.
• Storage systems in datacenters also face a practical limitation on the amount of data that can be stored compared to the amount of time the organization is willing to wait to make the data available for use. At some point, the organization must invest in more physical space to store disks, tapes, etc.; the systems themselves; and people to keep them managed effectively if their overall needs for storage must grow. Cloud systems providers can dynamically expand storage capabilities to meet both increasing and decreasing demand for data storage (and timely access) by a customer, again via minute-by-minute rental of storage resources “local” to the cloud provider or from other providers.

The first and most important issue to understand is that your organization, as a user, is still completely responsible for the security of information and processes it hosts via cloud system providers. The CIANA+PS needs of your organization do not change as you migrate systems to the clouds; what does change is your choice of controls and methods to achieve those needs. Your needs for disaster recovery and business continuity services, in terms of responsiveness, alternate operating locations, and security, do not change, even though using a cloud provider may make them easier to achieve.

---

How many cloud services?

The typical enterprise organization uses over 1,400 different cloud services, according to research in 2020 done by Jasdeep Basra and Tanu Kaushik, UC Berkeley's Center for Long-Term Cybersecurity. And those services are all a part of the threat surface that the enterprise must contend with.

Cosponsored by McAfee, the report makes for sobering reading. See it at https://cltc.berkeley.edu/2020/10/06/mitre-attck/.

---

Regardless of deployment model and degree or types of services, your organization is going to have to depend on its technical staff in the IT department and on the information security team to understand the many different service capabilities your cloud hosting provider can offer. Your people will have to understand how to use these features to get the best performance and security for the money being spent on the cloud. To illustrate this, consider that early in 2018, research by Gartner and others showed that the number one cause of data breach or compromise for information stored by clients in the cloud was incorrect settings of security and access control parameters, on that storage, by the end users themselves. Thomas Fischer, reporting at IDG Connect (www.idgconnect.com/idgconnect/opinion/1002869/common-causes-cloud-breaches), goes on to point out that by 2020, according to Gartner's research, “over 95% of cloud security incidents will be the customer's own fault.”

Your organization, and you as an SSCP, must thoroughly understand the contract, service level agreement, or terms of reference document that sets the legally enforceable duties and obligations that you and your cloud host provider have with respect to that contract. This cannot be overemphasized! To most cloud-hosting providers, especially the market-leading ones, your organization is one of thousands if not millions of businesses moving into their clouds; they do not know your organization, and they do not understand your CIANA+PS needs. For a (potentially) hefty consulting fee, they will work with your team, of course; even so, your team needs to know the legal as well as the technical ground on which you're going to operate. This is often called the shared responsibility model in which the cloud services provider and the customer organization document their agreement about different responsibilities.

Please note that much of the detailed mechanics of identifying and resolving information security risks for cloud-hosted business logic are beyond the scope of this book, as well as beyond the scope of the SSCP exam. Other certifications, such as (ISC)²'s Certified Cloud Security Professional (CCSP), may provide you the path you want to take if you need to become more of an expert at keeping cloud deployments safe, secure, and resilient. With that caveat, let's soar onward and upward!

Cloud Deployment Models and Information Security

Currently, industry offers three basic models for deploying your business logic and business processes into the clouds: public, private, and a mix of the two commonly called hybrid. All use the same basic virtualization technologies to provide processing, storage, network definition, webpage and Web service hosting, database capabilities, and a variety of other services. The key differentiator is not so much who owns the underlying hardware and software that is the cloud infrastructure itself, or who maintains it, but what other organizations or businesses share that infrastructure as cloud customers:

• Private clouds restrict user organizations to a specific, named set (such as a single business, its vendors, and its strategic partners).
• Public clouds provide access to any organization that wishes to contract with the cloud-hosting service provider.
• Hybrid clouds serve the needs of a single organization, or its designated partners, vendors, etc., by means of a mix of private cloud and public cloud systems.

A special case of the private cloud model is the government cloud. In this model, a specific government agency (local, state, regional, or national) contracts for cloud-hosting services for its business processes, which may be inward-facing (serving agency users only), public facing, or a combination of users to suit the agency mission. Whether the government cloud is hosted on hardware and systems exclusive to that agency (regardless of who owns and maintains them, or where on the planet they are physically located) or on shared, fully public clouds is largely a moot point.

From the SSCP's perspective, the difference in deployment models and the security capabilities they provide is largely one of degree. Private clouds may allow the organization full visibility into, control over, and responsibility for proper disposal of computing equipment that may have residual data still in it, for example. Public cloud providers have this responsibility, and their own business case dictates to them how they handle zeroizing or randomizing of storage media before it leaves their physical control in order to meet the confidentiality needs of all of their customers put together. Private clouds hosted on equipment the organization owns, leases, or manages, at locations it has complete control over, may allow a safe transition path from private datacenter to the clouds, while the organization is still learning about cloud system capabilities and security capabilities. As you might expect, the many different ways that hybrid deployments can be done provide a wide range of options to consider in terms of capabilities and information security approaches.

Cloud Service Models and Information Security

On top of the decision to go private, public, or hybrid is another choice, driven as much by the organization's business logic as by its applications and data architecture and strategy. Recall from Chapter 4 that everything we do in the clouds is done by requesting and using services. The major service models you'll find today are:

• Infrastructure as a service (IaaS) provides CPU, storage, software-defined networking, and server capabilities on which users can host databases, compute-intensive applications, and other elements of their business logic. IaaS can be as simple as bare metal servers that require (and enable) the user to be in total control of defining, creating, dispatching, and using virtual machines, running on hypervisors selected by the user, or they can include a variety of system capabilities to make virtual machine creation, deployment, use, and retirement from use easier to manage.
• Software as a service (SaaS) provides a layer of application software on top of an IaaS foundation. End users who need cloud-hosted productivity suites, for example, or a rich set of software development environments, tools, and test facilities may find SaaS an effective service model.
• Platform as a service (PaaS) provides a large-scale, feature-rich applications platform, again on top of an IaaS foundation. Platforms usually integrate data modeling, data management, and data backup, restore, and failover capabilities focused on the application services the platform delivers to its users.
• Identity as a service (IDaaS) delivers integrated sets of identity management services. This is focused on the infrastructure-level services of defining, managing, provisioning, and monitoring identities of end users, tasks, processes, and other information assets (such as hardware devices and databases. IDaaS is considered an example of services delivered via PaaS by some, while others consider it a service model in its own right. What matters to the practicing security professional is to understand what a specific IDaaS system or vendor is (or is not) providing, and how that service is measured, managed, and delivered.

Consider a small desktop publishing content firm as a simple example illustrating the differences between SaaS and PaaS implementations. Prior to considering a migration to the cloud, the firm may be using a variety of applications for word processing, page layout, webpage design and implementation, and other content development, provisioning, and management tasks. As a set of separate applications, they may not have an integrated document library management system or integrated backup and restore capabilities that provide versioning, fallback points, or other features that would empower the firm's growing needs for business continuity as its customer base grows. Moving to the cloud via SaaS merely moves those same apps, and their folder trees, into the cloud. PaaS models, by contrast, would look to use a larger, more feature-rich platform application that brings all of those features together, around an integrated data model. At some point, moving from applications to a platform may make a lot of sense for this business.

Think of these models as layering on capabilities, as they go from bare-metal infrastructure on up to platform services. Each new layer of functionality changes the way the cloud customer organization thinks about defining its business logic in that cloud, how it carries it out, and how it protects it to meet its overall information security needs:

• In a bare-metal IaaS environment (with or without the hypervisor provided by the host), the customer must select and build the operating system and other infrastructure services, such as identity management and access control, that they need both within their cloud space and at the threat surface where it faces the rest of the Internet (be that customers or crackers). As the customer adds on additional applications or app platforms, further attention to detail is necessary to ensure that these are implemented safely and securely. Disaster recovery and business continuity capabilities, even simple restore point recovery functions, must be added in by the customer.
• Moving up to SaaS environments usually means that the VMs that the customers deploy (as their workload demands more CPU power, for example) bring with them a built-in set of security policy capabilities. The apps themselves (that are the “software” in SaaS that the customer is renting time with) are probably preconfigured to provide a reasonably secure operating environment.
• Moving up to PaaS environments usually relies on the customer defining work roles (such as “order entry” or “HR hiring manager”) to people on their staff and assigning built-in sets of privileges associated with those roles. The roles bring with them platform-defined and platform-enforced identity management and access control functions, which make use of the virtual host operating system's own such features.

Edge and Fog Security: Virtual Becoming Reality

Two additional architectural models for cloud computing bring us closer to where the virtual, modeled existence of things and ideas becomes the physical reality of machines, people, and the movement of physical objects. Both of these models add additional layers of concern to security planning and operations.

Edge computing refers to cloud-based computing architectures that do the majority of the data processing at or very near to the endpoints themselves. This tends to use large, high-performance processing nodes out near the literal, geographic boundaries of the organization's information infrastructure. Local, smaller-scale versions of corporate datacenters might be colocated in branch offices in distant countries; content distribution networks might use a mesh or star arrangement of servers that replicate and then stream content, even live programming, to end users. Many industrial control architectures use edge computing architectures, in which regional or area control centers take on the computation, data and protocol transformation, and subsystems management tasks needed to directly control sets of process control devices, instrumentation, and related equipment. In each of these use cases, the edge servers and the cloud datacenter are exchanging data and commands at a more strategic level, while the edge servers are more directly involved in real-time device interaction.

Fog computing breaks the edge model down into layers, you might say. The core of the model is still the datacenter as hosted on the cloud; a fog layer places a layer or ring of high-performance computing resources around that datacenter, with each such processing node servicing only a (somewhat localized) portion of the endpoints requiring services. Now, connect another, outer ring or layer of edge computing servers, and their associated sets of supported endpoints, and you have a complete fog-edge-cloud architecture.

Fog and edge computing do have a lot in common, and they are often seen as variations of the same concept. It's interesting to note that in a growing number of industrial or process control applications, the same types of gateways are used to transform IP network traffic into device-specific commands, timing, and data signals. This can allow an organization to choose how far into the cloud they want to locate the processing load (and its security controls).

Retail banking systems are a prime example where a private network (via LANs or VPNs) is used to connect ATMs and teller workstations to cloud-hosted bank business processes. The endpoint devices, along with any branch or local office-based support processors, form the edge of the architecture; the private network, its access control, data integrity, and servers, form its fog layer. Common, centralized bank services for account management, transaction clearing, and interfaces with the global electronic funds transfer systems, would be in the bank's cloud systems.

Balancing Performance with Security

Edge and fog computing both provide the organization with different ways to balance data consistency and integrity, data redundancy, processing, and network traffic to meet their needs. As a result, any given dataset—which might be real-time high data rate feeds of live data or on-demand viewing of gigabytes of infotainment content—is potentially at rest in multiple locations, in transit between many more, and in use in a variety of ways, all at the same time across the overall architecture. In a pure edge computing model, the edge servers and processors are directly supporting their sets of client endpoints, without any additional or substantial computing layers in between. For process control applications, particularly those where safety needs may be of paramount importance, maintaining device-level security—protecting all data and commands sent to the device, as well as protecting all data generated by the device and its associated sensors and monitors—quickly becomes a multilayer, edge-to-center problem.

Most information systems architectures—whether IT, OT, or any blend of both—rely on each device (real or virtual) in the architecture to do its share of the processing, as part of balancing processing speed, security, throughput, and costs across the architecture. As more value-added processing is pushed to the endpoints, and as this increases data storage requirements for those endpoints, securing that computing edge of any organization, no matter how virtual it may be, becomes more challenging. Coping with that challenge requires that we adapt time-tested advice for criminal investigation to our design, monitoring, and assessment of an edge or fog computing system's security.

Follow the money; follow the data. Follow the command and control flows and the flow of observations and feedback information that should result from those command and control actions. Then, cui bono, as has been said since the days of the ancient Roman empire: ask yourself what entities or users benefit from that flow you've just followed. And if the answer to that question doesn't meet with the approval of your security policies and identity management and access control system, you may have an intruder in your midst.

Clouds, Continuity, and Resiliency

We've seen how the combination of deployment models and service models give your business or organization a rich set of options when it comes to providing a new home for your business logic and information systems. The inherent flexibility and scalability of any cloud solution, as you apply it to the growing needs of your business, bring with it key aspects of availability: continuity and resilience.

Both of these related terms describe how well business processes and logic can operate correctly, safely, and securely despite the occurrence of errors, failures, or attacks by threat actors (natural or human). It's important to keep these two terms separate and distinct in your mind as you plan your cloud migration and keep it up and running:

• Continuity measures the degree to which a system can produce correct, timely results when input errors, missing data, failed or failing subsystems, or other problems are impacting its operations. Designed-in redundancy of critical paths or components can provide a degree of graceful degradation—as elements fail, or as system resources become exhausted, the system may provide lower throughput rates, produce more frequent but tolerable errors, or stop executing noncritical functions to conserve its capabilities to fulfill mission-essential tasks. Cloud-based systems might slow down dispatching new instances of VMs to support customer-facing tasks, for example, when there aren't enough resources to allow new VMs to run efficiently; this might slow the rate of dealing with new customer requests in favor of completing ongoing transactions.
• Resiliency measures the ability of the system to deal with unanticipated errors or conditions without crashing or causing unacceptable data loss or business process interruption. Auto-save and versioning capabilities on a word processor application, for example, provide resiliency to an author in two ways. Auto-save protects against an unplanned system shutdown (such as inadvertently unplugging its power cord); at most, the user/author loses what was typed in since the last automatic save. Versioning protects against the off chance that users make modifications, save the file, and then realize that they need to undo those modifications.

There's an interesting natural chain of consequences here, best illustrated by one key feature of loud solutions and the datacenters that support them alike: load balancing. Suppose our datacenter has 100 compute servers, each consisting of 16 CPU cores and 1 TB of onboard RAM; such a bare-metal server might be able to host 30 good-sized, highly functional virtual machines. As customer (or system) demand for more VMs increases, the load balancing and dispatching tools put each new VM on a different hardware server and on a different CPU core. The failure of one CPU or even one server therefore disrupts fewer customer work streams than if the dispatcher fully loaded the first core on the first server, then the second core, and so on.

Load balancing is an excellent example of a built-in capability to provide continuity in the face of rapidly changing demands for services. It also provides a degree of resiliency. Many systems, such as a national electrical power grid, have to deal with larger-than-anticipated swings in demand (or supply), often caused by natural disasters or other major events. As a designer, you can only plan for so much; after that, you trust that the inherent flexibility of what you've built will help it weather the storm.

Clouds and Threat Modeling

Still, the real security question that the SSCP must grapple with is this: where is the threat surface between what we keep “private” inside our cloud and what we expose or offer to the outside world? Chapter 4 introduced us to threat modeling, which is a deliberate, purposeful task that seeks to define these boundaries between “inside, keep it safe” and “outside, let it be exposed to some risk.” Concentric layers of threat surfaces are common in any IT system, after all; as design paradigms, these surfaces guide systems analysts and administrators in deploying the bare metal, the OS, then layer upon layer of functionality (such as identity management and access control management systems), finally adding layers of applications. On top of that apps-shielding threat surface is a space in which the typical end user has a limited set of privileges over some assets—he can create or delete his own files, in his own area of the file system, but not touch someone else's, for example.

It's also important to ask how the threat model (or threat surfaces) have changed, or will change, by migrating into the clouds. If the underlying business logic remains the same, the logical relationships between subjects (people or tasks) and information assets doesn't fundamentally change; roles, purposes, and trust criteria should not change just because of where assets or functions are hosted. (Should they?) What does change is the physical, logical, and administrative connection from subject to asset. At a minimum, this changes the nature of the crossing point on the threat surface; it may also introduce new threat surfaces interposed between subjects and assets, with their own crossing points or portals that need to be understood, controlled, and monitored.

It may be useful to compare a threat surface, or the idea of using threat surfaces, to maps and diagrams we use to plan and manage access to physical buildings, their surroundings, and their support systems. The paper map that shows the building, property entrance, alarm zones, and even the nearest fire hydrant is not the physical building, the plumbing, or pavements. It's just a model that helps us humans organize our thinking about normal workday traffic and activity, emergency responses, or how to increase security after business hours. We can drill down into that paper map by opening up other paper files, and learn where the fire alarm station is that seems to be ringing right now. When we put that map on an alarm annunciator panel or a dashboard, it still is showing us a model of the physical property—and as we make that display more interactive, and more integrated with the rest of our information systems, it becomes a geographic information system in miniature.

These threat surfaces do not need to be complicated. In fact, we can argue that if the SSCP starts out with simple threat surfaces, this can clarify everyone's thinking and drive toward identifying both potential vulnerabilities and appropriate control strategies for them. The key is to look at the overall system in terms of these perimeters and boundaries; information at rest is resting within a particular boundary, and it should not move across that boundary unless you and the system owners have decided to authorize that move. If it is authorized, you still need to worry about how (or if) to protect the data while it's on the move. (This, by the way, is the key to getting a grip on the data exfiltration problem.)

As we noted earlier, how your cloud host provider deals with data storage devices and protects your data while in motion, in use, and at rest in its cloud spaces should be part of your threat modeling considerations too.

---

Migrating the Threat Surfaces to the Clouds

Amber is part of the information systems team at a small, private junior college, which has been using its own local network of computers to provide its own homegrown applications and platforms to handle student prospecting, student and class administration, faculty and staff human resources management, and other administrative functions. The school's website is hosted on a third-party Web hosting provider, and currently provides only email forms to request information or to contact the school. Right now, all of the administrative, IT, support, and classroom facilities are in the same building. There are about 40 faculty and staff and six classrooms; Wi-Fi access for faculty, staff, and students requires a valid network login (such as student or staff ID), and guest access is also supported.

As the school is growing, it needs to expand these systems to handle more classes, more students, and more buildings. It's considering cloud-hosted solutions, either as PaaS or SaaS models, or a combination of both.

Knowing you're an SSCP, Amber has asked you for some help with threat modeling. She thinks she needs to show her department head, and others, what the threat model looks like now, and what it might look like after the school moves into a PaaS-plus-SaaS environment.

Key risk areas that Amber knows must be addressed include:

• Student and staff personally identifiable information; other information protected by law (such as student records, payment records, employment files, etc.)
• Admissions, enrollment, class participation, and progress data (to prevent clever students from hacking a “straight-A” record for themselves or their friends)
• IT labs, currently hosted on hardware in the IT classroom, that are used for cybersecurity, white-hat hacking, and malware analysis student projects

How would you draw the threat surface (or surfaces), or model the threat environment, for the school as it is currently operating? Does this model represent a requirements baseline it should seek to achieve when it migrates into the cloud?

How would you see that threat model changing as the school migrates into the cloud?

---

Cloud Security Methods

As with any information system, security depends on choosing the right set of cloud system features and capabilities to meet the CIANA+PS needs of the organization.

Key to these are access control, authentication and audit, data integrity and data recovery capabilities, and protection of information at rest, in use, and in motion. The choice of cloud-hosting provider should consider both the deployment model (platform, software, or infrastructure as a service) and the inherent security capabilities provided by that host; security-related expectations and requirements need to be defined in a contractually binding terms of service (TOS) or service level agreement (SLA) between the organization and the cloud host.

It's also a question of scale. When securing your on-premises LAN, consisting of a few servers and a dozen or more workstations, you know all of the things you need to do to keep that LAN safe and secure. You'd limit or eliminate public-facing IP addresses, using proxy services to allow the public, potential customers, or real customers to access your systems. You'd segregate functions so that services and functions that had to face the Internet were isolated from those that needed greater protection. You'd use allowed listing strategies to lock down ports and services that you don't need to expose to the Internet, and control what apps can install and execute. You'd manage this set of systems as a baseline. You'd monitor it and assess its ongoing security effectiveness, possibly even with penetration testing.

In the cloud, your same business now may be seeing a dynamic, ever-changing number of virtual machines that are providing much that same set of functions, maybe even segregated out in similar ways. The only real difference is that the number of VMs that are running copies of those functions, in coordinated, load-balancing ways, changes moment by moment based on user demand for services.

This may actually be the silver lining in the cloud. Limit the number of types of VMs that you're going to use; make sure you thoroughly understand everything that each of them needs to do. Know which security capabilities the cloud-hosting provider offers that make it easy to define the VM template as fully secure as you need it. Then you just create and control the load-balancing rules that allow the cloud host to spawn more copies of each template when conditions demand it.

Finally, ensure that you and your networks team members thoroughly know how to exploit your cloud host's features for software-defined networks (SDNs). The same threat modeling and security techniques we looked at in Chapter 5, “Communications and Network Security,” still apply (no matter where that virtual SDN is, it's still running TCP/IP, after all).

Integrate and Correlate

Even the most cloud-native organization relies upon a combination of physical, real-world endpoint devices, its suite of cloud services (including its many forms of data storage), and the networks that interconnect all of that and make it useful. Most of the network is, of course, in the hands of the Internet service providers and the Internet infrastructure itself; nonetheless, that does not remove the burden of due care and due diligence from the organization's leadership for the risks they share with those providers. Actively addressing those duties requires gathering precursor and indicator signals from all of those elements of the organization's systems for use by SIEM or other security information management systems to organize, manage, correlate, and use as part of real-time and near-real-time incident detection and characterization. It seems simple enough: gather all the data that you're already paying for, and make use of it. Yet research shows that as of 2020, as many as 61 percent of enterprise organizations fail to do this.

This integrate and correlate strategy (as part of an all-source intelligence and threat warning process) is not just for the large enterprises. SMBs and SOHO organizations can and should do likewise. For the smaller organizations, an incremental approach is both acceptable and advisable: it's better to bring each infrastructure element or service provider, one by one, into an integrated detection, characterization, and incident warning analytical environment than it ever would be to wait until all such sources are identified and a cohesive solution is implemented. Procrastination by the defense planners assists only one's adversaries.

SLAs, TORs, and Penetration Testing

We've looked at this in other sections of this book, but it bears repeating. When you decide to conduct penetration testing of any system, law and contracts require that you have the knowing consent of the target system's owners, operators, and responsible managers. If your well-intentioned penetration test takes down business processes, or causes other disruption or damage to the business, that signed, binding acknowledgment and acceptance by your own company's officials may be all that keeps you employed, or even out of jail! This situation gets even more complex as your business moves parts of its business logic and systems into a public or hybrid cloud, for it's conceivable that your pen tests against those systems could inadvertently disrupt other customers of that cloud-hosting provider or the cloud host's overall operations.

Before any serious planning of such cloud-based penetration testing begins, get with your managers and consult the contracts, the service level agreements (SLAs) or terms of reference (TORs), sometimes called terms of service, or TOS, that your organization has with its cloud-hosting provider. Understand any requirements to notify the cloud host; work with them to ensure that your test plan makes sense and contains the proper safeguards that they require.

Data Exfiltration II: Hiding in the Clouds

Once in the clouds, the data exfiltration threat landscape facing your organization may see one important factor change in ways that can favor the attacker. Simply put, most organizations see everything about the IT side of their business expand dramatically as they move from on-premises computing into a cloud system. The numbers of attempted connections, numbers of authenticated users actually connecting, and number of services requested per day increases, perhaps by a factor of 100, 10,000, or more. Transaction volumes increase; the amount of data stored overall, on a per-function or per-user basis, increases to support the business logic that services the needs of all of these new prospects, customers, and transactions.

If data thieves want to steal your entire customer file, then of course their target of choice has gotten bigger. Huge file movements might be easier to detect (probably after they've happened). But if thieves want only a few customers' PII, credit card, or billing information, or have a way to take just one or two customers' worth of data out on any given attack, then those small transactions seem even smaller in contrast with the overall volume of activity.

Keeping your data safe in the clouds will require a more comprehensive approach, one that integrates secure email systems, data loss prevention techniques, and much more robust identity management and access control than you may be accustomed to from your pre-Cloud workplaces. DLP systems and services, for example, often are implemented as a combination of host-based, cloud-based, and enterprise-wide service architectures, with each playing an important role in your overall data security program. And don't forget the IoT and OT elements of your organization's total systems architecture, as you put your cloud security strategy into motion.

Legal and Regulatory Issues

Whether your business or organization has the IT systems that support its business process cloud-hosted, on local on-premises computers and LANs, or on paper files doesn't matter very much when it comes to the ever-growing complexity of legal and regulatory constraints and requirements organizations must live up to. In many nations, laws and regulations can exist at the local (municipality) level, at the state or province level, and at the national level. Treaties and international agreements entered into by their host nation also bind the corporate citizens of that nation to those international constraints and obligations as well. Industry groups may also impose standards, such as the Payment Card Industry Data Security Standard (PCI DSS), to ensure that transactions across their marketplaces are safe and secure.

Three major sets of issues arise when we consider doing information-based business in ways that touch upon multiple jurisdictions:

• Data in motion, as it crosses the borders between jurisdictions
• Data at rest, and the abilities of authorities to search it, copy it, seize it, censor it, or otherwise interfere with its use by the organization
• Data in use, which one jurisdiction may find objectionable while another does not

The continuing controversy of Google's attempts to deploy search engine capabilities that meet the needs of the marketplace but also meet the demands of the governments of countries such as the People's Republic of China, illustrate all three of these sets of issues. A number of nations in the Middle East also have attempted to control, restrict, or outright block the movement of data across their borders. Privacy concerns cover a wealth of information, such as identity, health, insurability, education, employment history, and credit data, and the processing, storage, and disposal requirements for each of these sets of information differ across different jurisdictions. Even data about prior arrests and convictions can be private and protected in one jurisdiction but public and published information in another.

Cultural standards also can cause a border-crossing information enterprise a variety of problems, often incurring legal problems. For example, the anime genre of illustrated novels and animated movies often depicts relationships and activities involving young people that are quite acceptable in Japan, where anime originated and much of it is produced. But in other cultures, it is sometimes considered to be child pornography or encouraging the sexual exploitation of children. Other images, art, or music that might be critical or satirical in one context can be blasphemous, heretical, or treasonous in another. (If you've been looking for another good reason to update your organization's acceptable use policies for your IT systems, this might be it!)

Legal and regulatory requirements also dictate how individuals can discover data that organizations hold that pertains to them, examine it, dispute its accuracy, and seek corrections and redress. Other requirements dictate both minimum and maximum periods that organizations must hold data of different types, and how and when they must dispose of it.

These requirements fall upon the organization that gathers, creates, stores, uses, moves, and destroys or disposes of the data. They also flow down onto third-party organizations, such as service providers working with that business or organization. Note that in most jurisdictions, your organization (as the prime contractor) is on the “hot seat” for whatever your subcontractors or third-party service providers do on your behalf. As with your employees, they are working under conditions you set, paid by you to perform tasks, and that includes staying within the laws and regulations that apply to them in their place (or country) of jurisdiction. So while these third parties are responsible and liable to the courts themselves, so are you! Even if you can show that they acted outside of the scope of your agreement, and without your prior knowledge and consent, your company is at risk—in the courts of public opinion and marketplace goodwill if nowhere else.

Consider one complication that could arise when moving to the cloud. Where, physically, does your data reside? What borders does it cross on its way to and from your company? Which sets of laws, customs, regulations, and expectations apply?

As you can imagine, a full understanding of many of these legal and regulatory issues is well beyond the scope of work that the typical SSCP will encounter. That said, you'll still need to know that such laws and regulations exist and that someone in the company's legal team needs to be the resident expert on what they mean to the company.

Countermeasures: Keeping Your Apps and Data Safe and Secure

Whether the apps in question are large-scale, complex platforms or small, lightweight, appliance-sized bits of functionality, the same countermeasure strategies and approaches should be considered as part of an overall IT risk management and mitigation program. We've worked through the mechanics of each of these steps earlier in this or in previous chapters; let's see them taken together in a high-level summary fashion:

• Know and understand your organization's tolerance for information risk.
• Document and maintain the baselines that keep your organization alive and well: its information, information systems and processes, and IT infrastructure.
• Establish and use sufficient configuration management and change control over all information resources, including software development, test, deployment and support systems, tools, files, and other resources.
• Perform a thorough vulnerabilities assessment, making use of common vulnerability and exploit information, vendor-supplied security information, and the insight and experiences of your own people.
• Prioritize risk mitigation and control implementations in accordance with risk tolerance and guided by the vulnerabilities assessment.
• Implement, maintain, and monitor identity management and access control systems and procedures.
• Monitor application-generated and system-generated log files for suspicious activity.
• Work with applications end users throughout the organization to address training and education needs related to applications and data security, safety, and protection.
• Use design paradigms, patterns and templates, coding standards, and development processes that are reliable and repeatable and that support the development of secure, safe, and resilient applications.
• Use rigorous test processes (including analysis of test results) to ensure that high-risk functions are as free from vulnerabilities as possible and work correctly.
• Ensure that vendor-supplied updates, patches, and security fixes are assessed for applicability and compatibility with your systems, applications, and business processes, and implement them as soon as practicable.
• Work with developers and maintainers to ensure that initial and ongoing secure software development training needs are being met.
• Work with management and leadership to address human factors, such as insufficient separation of duties.
• Train and educate all staff members regarding the real, present danger of social engineering attacks. Strong application of the need to know principle would exclude almost all outsiders from the generalities and the details of our internal processes for building, maintaining, and solving problems with our applications and data.
• Perform ongoing security assessments of all aspects of applications and data development, deployment, use, retirement, and disposal.
• Ensure that disaster recovery and business continuity planning can be effective in providing failover and restore capabilities; fallback to earlier known, safe configurations; and archival copies of systems and data as required.
• Review all contracts, TORs, SLAs, or memoranda of understanding that transfer any element of risk, service performance, or service support to any outside party, to ensure that your information security needs as they pertain to those agreements are correctly and completely documented.

Yes, that looks like the complete set of task areas that information systems security teams need to address in many organizations. If we look at that list strictly from the point of view of our apps—if we apply this list only to the way we get apps built, tested, deployed, and then how we use those apps day to day in our business—we are seeing that entire “information security” job jar from the endpoint perspective.

Summary

Keeping the endpoints of your organization's information systems safe, secure, reliable, and resilient has never been more important. In many respects, endpoint security is vitally dependent on the CIANA+PS approaches you take to securing the information infrastructures that support those endpoints. Identity and access, monitoring and analysis, ongoing assessment, and constant vigilance apply at all levels of our information architectures. All of this, as you've seen, is or should be driven by the prioritized risks as identified by the BIA. Moving parts or all of your organization's business logic into the clouds adds many technical nuances to achieving information security

The endpoint perspective we've explored together in this chapter is very object-oriented in nature. By itself, this perspective says, data just sits there. It takes other objects, processes, or people, subjects as we called them in Chapter 6, to create, change, destroy, move, or copy data to another location. When we combine this idea with the basics of threat modeling and use a threat surface approach, we reveal those channels in which subjects can access our data objects; this focuses our attention on those channels we want to authorize, control, and monitor and on those we want to block (and monitor).

Applying a lifecycle model to the development and use of both applications and data has also helped reveal key opportunities to achieve better information security. Many of the common vulnerabilities in applications software, we've seen, stem from ineffective management of the software development process used to specify, create, deploy, and maintain that software. This is another example of the claim in earlier chapters that unmanaged systems are most vulnerable to exploitation. Data quality, or the “garbage in” side of the equation, also contributes to information insecurity; data quality, as we've seen, is separate and distinct from the CIANA+PS benefits of strong and effective access control, for example.

Moving parts or all of your organization's business logic into the clouds adds many technical nuances to achieving your information security requirements; the good news is that it does not really add any new fundamental ideas or principles to consider. Just more details!

Exam Essentials

• Explain the software development lifecycle (SDLC) in security terms.  All applications software goes through a lifecycle of a number of phases as it evolves from initial ideas, to requirements analysis, system design, software development and test, deployment, operational use, support, and retirement. There are many SDLC models, but they all have these same basic elements. At each phase, the information used and produced, such as design notes or test strategies and plans, can reveal exploitable vulnerabilities in that software. Ideally, design validation and test should evaluate how real these vulnerabilities are as risks to the user's data or to the organization. In most cases, this software design and test information should be treated as proprietary information at least.

  Explain application allowed listing and its use.  Allowed listing is a positive security control model—it explicitly names or lists approved activities, connections, files, users, or (in this case) applications that can be used. Organizations should only place trusted applications from trusted providers on such allowed lists, provided that they have also been through the organization's security assessment process, and for which provider-supplied security patches and other updates are readily available. Allowed listing should be able to provide specific users or classes of users with the specific list of apps necessary for their job functions; all others would be blocked from being installed or executed by these users. Software development organizations usually cannot use these techniques within their development environments, as they are frequently compiling, building, and testing new versions of software repeatedly through the day. Allowed list systems and the administrative policies that support their use may, at organizational discretion, allow for one-time exceptions or for users to submit requests for exceptions or additions to the allowed list. Obviously, the less control over the allowed list itself, the greater the risk of unauthorized apps being executed.

  Compare and contrast positive and negative models of applications and data security.  Positive models of security explicitly name and control allowed behaviors and thus automatically block anything not defined as allowed. Negative security models explicitly define prohibited behaviors and therefore authorize or allow anything that does not fit the definition of what is blocked. Antivirus systems are examples of negative security models, using either signature analysis or anomaly detection to flag suspicious or known malware and then block it from executing or spreading. Applications allowed listing is an example of a positive control model, as it defines a list of allowed executables to be used by a class of users or an individual user. Identity management and access control systems can be a combination of both positive and negative security models at work. It is estimated that perhaps a million pieces of new malware are created every day across the world, but any particular organization may only create a handful of new legitimate applications each day. Thus, allowed listing or positive security approaches are probably easier to implement and manage, and are more effective, than blocked listing or negative security models can be.

  Explain the role of IDEs in applications software security.  Integrated development environments (IDE) provide software developers and software project managers with a range of tools, frameworks, and processes that support many of the steps in the software development lifecycle process. Depending on organizational needs and culture, the right IDE can enforce the use of design patterns, data typing rules, test strategies, and problem analysis and error correction, all within an integrated configuration management and control framework. By providing visible management of the software lifecycle, the right IDE and configuration management (or builds and control) tools can reduce the risk that unmanaged software is deployed with known but unresolved exploitable vulnerabilities, which reduces the information security risk the organization faces.

  Identify possible security risks in various software development lifecycle models and frameworks.  Managing software development and deployment is a constant trade-off between how many required functions can be built, tested, and validated, in a given timeframe, using a given set of development resources; further, the deployed product may contain an undetected exploitable vulnerabilities. Some models and frameworks emphasize up-front requirements analysis, data validation, and other quality approaches, which may reduce the risk of producing software with such vulnerabilities. Other approaches, such as agile and rapid prototyping, quickly produce working software as a way of understanding the desired functionality. Test-driven or test-first methodologies may reduce these risks, with their emphasis on quickly writing code that tests what the requirements are trying to get accomplished (that is, testing what the business logic needs to do). Each is only as good at reducing the risk of producing insecure code as the manner in which it is managed.

  Explain the need for threat modeling when considering migration of business processes into cloud-hosted environments.  Threat modeling uses the concept of the threat surface, the logical, physical, and/or administrative boundary between the information assets inside the boundary, and all processes, users, or systems outside of the boundary that attempt to communicate with, confirm the existence of, learn about, access, or change those assets. Complex systems usually have multiple such threat surfaces. Migrating into any cloud-hosted environment demands that this threat surface be well understood and that all ways that such a threat surface can be crossed are known and under control.

  Describe the key issues in operating and configuring security for cloud-hosted systems.  The first and most important issue to understand is that your organization, as a user, is still completely responsible for the security of information and processes it hosts via cloud systems providers. The CIANA+PS needs of your organization do not change as you migrate systems to the clouds; what does change is your choice of controls and methods to achieve those needs. For example, moving to a public or hybrid cloud system means that your data, processes, and users are sharing CPU, network, and storage resources with other users—possibly even with your competitors. This may dictate more stringent means to ensure data is secure at rest (when stored in the cloud host's systems), in motion, and in use on your authorized users' endpoint devices and systems. You'll need to ensure that the host can meet or exceed your business continuity needs, such as maximum allowable outage. Finally, you should thoroughly understand the contract, SLA, or TOR document that sets the legally enforceable duties and obligations that you and your cloud host provider have with respect to that contract. For example, you may be liable for damages if malfunction of your processes cause other users of that same cloud host to suffer any performance degradation or data losses.

  Explain the key security issues pertaining to various cloud deployment models.  Organizations can deploy information processes to the cloud(s) using systems that support their needs exclusively, that are fully shared with other unrelated user organizations, or that are a mix of both. These private, public, or hybrid cloud deployment models present different information security issues—but in and of themselves, a choice of deployment model does not change the CIANA+PS needs of the organization. The key difference between private cloud deployments and public or any hybrid approach is that in the private model, the organization has total control (not just responsibility) to carry out all actions necessary to ensure its information security needs are met. Public or hybrid cloud deployments depend on the cloud hosting provider making the business decision about how much CIANA+PS implementation to provide for each of its customers—and for all of its customers in aggregate. Such business case decisions by the provider should be reflected in how it implements customer data and process segregation and isolation; how it provides for data integrity, backup, and restore capabilities; and how it handles both data disposal and disposal of failed (or failing) hardware that may have data remaining within it. Additional insight as to how well (or poorly) the cloud provider implements data security for all of its customers may also be found by examining how it handles encryption, access control, identity management, and audit, and how it addresses data remanence in these systems and technologies, too.

  Differentiate the security issues of SaaS, PaaS, and IaaS cloud service models.  All three cloud service models (or any mix thereof) require user organizations to thoroughly understand their own CIANA+PS needs for information security and be technically and administratively capable of working with their cloud services provider to implement and manage core security functions, such as identity management, access control and accounting, and anomaly detection, incident characterization, and incident response and recovery. The key differences in these models from the SSCP's perspective is the degree to which the user's organization has to depend on the cloud services host to implement, manage, and deliver the security functionality the organization needs. Software as a service (SaaS) solutions, for example, often involve using productivity suites such as Microsoft Office 365 to provide software functionality to users. SaaS providers manage the security of the applications themselves (as well as the underlying systems infrastructure), but in doing so they are not providing any integrated data management capabilities. Individual users are still responsible for keeping hundreds if not thousands of data files—documents, spreadsheets, databases, etc.—correct, up to date, and cohesive as meeting the organization's business needs. PaaS models provide a “platform” as an integrated set of software capabilities and underlying databases, which might represent a single line of business or function (such as human resources management) or the entire business. As a result, ensuring sufficient, cost-effective CIANA+PS depends on thoroughly understanding how to configure, manage, and use the platform's capabilities, including those for business continuity and restoration. IaaS offers the “bare metal plus” of the infrastructure by providing little more than the hardware, communications, storage, and execution management capabilities, along with the host operating systems to allocate such resources to user tasks while keeping those user tasks and data separate and secure from each other. The user organizations must each use these infrastructure capabilities (powerful though they may be) to implement their own data, applications, and communications security needs. Ultimately, the choice of model may depend on whether the organization has its own robust, secure platforms it is migrating or if its current systems are less than well integrated from an information security perspective as a whole.

  Explain how the use of virtualization and related hypervisors relates to applications and data security.  Almost all cloud deployment models use virtual machine (VM) technologies to provide user application programs and data in a logically separate execution environment. Hypervisors are the systems software that manage the allocation of hardware resources (CPU, memory, communications, and storage) to user VMs. VMs can be created, put into operational use, achieve their allocated piece of the business logic or purpose, and then terminated and decommissioned in less than a second. Since most cloud deployments will require many such execution environments (or VMs) being used simultaneously to meet their customer and end-user needs, it is imperative that the creation, deployment, use, and decommissioning (or disposal) of these VMs upon task completion is all configured and managed correctly. Most hypervisors will provide the management and deployment infrastructures necessary to keep individual VMs and their data streams separated and secure from each other; however, most organizational information processes and business logic will end up integrating all of the data used by those VMs into one cohesive data environment, keeping it current and secure throughout the business day. The specifics of VM configuration, deployment, and management are beyond the scope of the SSCP exam; however, SSCPs should be aware that effective use of cloud services in any fashion requires the user organization to understand and appreciate the implications of such deployments to organizational information security needs.

  Describe the possible legal and regulatory issues that may arise when deploying to public cloud systems.  In most cases, moving to a public or hybrid cloud environment exposes the organization to the legal, regulatory, and cultural requirements of different nations (if the business is not in the same country as its cloud systems provider); each nation can exert its separate jurisdiction over what information the business has and how it uses it. Different legal frameworks may have conflicting standards about what information is (or is not) privacy related, and what protections are required. They may also impose different controls on trans-border movement of information, possibly even prohibiting certain information from entering or leaving their jurisdiction at all. Legal processes for search and seizure, for court-ordered discovery processes, and data retention requirements can differ. Different jurisdictions also may have very different laws pertaining to government surveillance of information systems and their users, and they may also have very different legal notions of what constitutes criminal offenses with information, such as slander, liable, negligence, profanity, heresy, blasphemy, “counter-revolutionary thought,” or otherwise politically unfavorable speech, subversion, incitement, and even espionage.

  Explain the role of apps and cloud systems providers regarding the security of data in motion, at rest, and in use.  If data is the lifeblood of the organization, then apps are the muscles and sinew with which the organization's mind uses that data to achieve purpose and direction; cloud systems, be they public, private, or hybrid, are part of the veins and arteries, the bones, the heart, and other organs, that make that possible. Apps must ensure (through their design and implementation) that only properly authorized user subjects are executing valid actions with validated data. The infrastructure itself (including the cloud systems providers) supports this with identity management, access control, service provision, and protection of all communication paths that cross threat surfaces. Note that this is a functional statement—apps do this, the infrastructure does that—and not a design statement that specifies how those capabilities are achieved. There are many choices to make to ensure that the combination of user education and training; application design and implementation; data quality; and infrastructure services selection, configuration, and use results in cost-effective information risk management. This choice is the essence of information risk mitigation.

  Explain the typical third-party roles and responsibilities pertaining to information storage, retrieval, and use.  Typically, businesses contract with customers, employees, and suppliers for goods and services; the business is one party to these contracts, and individual customers, employees, or suppliers are the other party. (Contracts are typically between two individual organizations or people and refer to those contracting as “the parties.”) A third party is one whom the business contracts with to help it fulfill a contracted service with one of its customers, employees, or suppliers. These third parties may provide a variety of information transmission, storage, access, processing, or retrieval services for the business. Third-party contracts should address the conditions under which such information is kept secure during use, during movement, and when at rest. Since each such service may have its own specified degree or level of satisfaction or success criteria associated with it, these are often called service level agreements (SLAs). An SLA might specify that a cloud services provider ensure that data is always available even if one of its physical datacenters is unavailable but that in no account should it host backup or archival copies of the customer's data in datacenters located in specific countries. SLAs also should specify under what circumstances the third party is to destroy data, the destruction method to be used, and the acceptable evidence of such destruction. Since no agreement can hold if it is not enforceable, and no enforcement can happen without there being auditable records of performance against the SLA, the business and this third party need to agree to what constitutes such an audit. The audit is the detail-by-detail inspection, analysis, and proof that both parties have lived up to the spirit and the letter of the SLA they both agreed to.

  Explain the role of archiving, backup, recovery, and restore capabilities in providing for data security.  As organizations execute their business logic moment by moment across each business day, their data—their information model of the real world of their business—moves forward in time with each transaction, operation, update, or use. Archiving provides a snapshot of a moment in time in the life of that data, and therefore of the organization and its activities. Archives support audits, analysis, trending, and regulatory or legal accountability functions, all of which support or achieve data integrity, nonrepudiation, confidentiality, and authentication needs. Because an archive represents a moment in time of the data, it can be used as a point in time to reset or restore back to, either to correct errors (by reversing the effects of a series of erroneous transactions) or to recover from hardware, software, or procedural failures. Although this may introduce the need to reprocess or re-accomplish transactions or other work, this ability to restore the data that represents a time in the life of the organization is critical to continuity of operations; it is what provides the continued availability after the restore point has been achieved.

  Explain the shared responsibility model and how it relates to achieving information security needs.  In almost all cases, organizations transfer risks to other organizations as a part of their risk management and risk mitigation strategies. This incurs a sharing of responsibilities in terms of due care and due diligence to ensure that the organization's information security needs are met to the desired degree. The simplest example of this is when a company wholly owns and operates its information systems infrastructure, applications, and data capabilities; even then, it is reliant on its IT supply chain, and (presumably) its Internet service provider or other communications providers for ongoing support. At the other extreme, organizations that do full deployments of their business logic and data to a public cloud provider (relying on thin client endpoint devices and communications capabilities) place far greater reliance on that cloud host provider to keep their business operating reliably. This requires a contractual basis, such as an SLA or a TOR that clearly identifies how each partner in that agreement delivers services and reassurances to the other at their agreed-to point of service delivery and interface. As with all contracts, this requires a meeting of the minds—the contracting parties have to achieve a common understanding of the legal, administrative, procedural, and technical aspects of what they are agreeing to do with and for each other. Without such a meeting of the minds, no such contract can be successful; indeed, in some jurisdictions, it may not even be enforceable.

  Explain the basic concepts of operating and securing virtual environments.  Unlike a single-user desktop computing environment, virtual environments, whether in the cloud or not, involve three distinct phases of activity: definition, deployment, and decommissioning. First, the user organization defines each type of virtual machine and environment it needs; this definition sets the parameters that define its resource needs, how it interacts with other systems (virtual or not), how its access to system resources and user data resources are to be controlled, and what programs can run on that VM. This definition or template also can set the rules by which the VM relinquishes system resources when done using them. It is during definition that information security services, such as identity management or access control, are selected, and their control parameters and policies are set and made part of the overall virtual environment of the VM. Next, the hypervisor will deploy as many copies of that VM as are needed to meet the workload demands of the business. As each VM comes into existence (or is instantiated), its definition invokes the interfaces to hypervisor-provided security infrastructures and features. Finally, as each VM completes its assigned tasks or is otherwise ready for termination, its allocated resources are returned to the system, and it ceases to exist as a valid process in the overall systems environment.

  Compare and contrast the information security aspects of software appliances and virtual appliances with more traditional computing approaches.  Using the appliance approach to deploying, maintaining, and using software allows organizations to trade flexibility, security, maintainability, and cost in different ways. As you move from highly flexible and adaptable general-purpose and open computing models to more specialized, closed systems models, you reduce the threat surface. Traditionally, users or systems administrators would install an applications program on each general-purpose endpoint device, such as a laptop, desktop computer, or even a smartphone. A computer appliance or hardware appliance is a physical device on which the application software, operating system, and hardware are tailored to support a specific purpose and users are prevented from installing other applications. A software appliance is an installation kit or distribution image of an application and just enough of the operating systems functions necessary for it to run directly on the target hardware environments. These turn general-purpose computers into special-purpose (or limited-purpose) appliances, much like a smart washing machine cannot make toast (even if its onboard computer is capable of loading and running a toaster control program). Virtual appliances are software appliances created to run direct as virtual machine images under the control of a hypervisor. In the traditional model, the application's user is exposed to all of the vulnerabilities of the application, other applications installed on that system, the general-purpose operating system, and the hardware and communications environment that supports the system. Appliances, by contrast, may reduce the exposure to OS and other applications vulnerabilities, depending on the nature of the tailoring done to create the appliance. Maintaining appliance-based systems by replacing failed units may improve system availability and reduce time to repair.

  Explain the key information, access, and data security issues related to the Internet of Things.  The Internet of Things (IoT) concept refers to devices with Internet addresses that may or may not provide adequate information systems security as part of their built-in capabilities. Whether these are “smart home” devices like thermostats, industrial process control devices, weather data or soil data sensors, or data-gathering devices on uninhabited aerial vehicles (UAVs), these “things” generate or gather data, send it to organizational information systems, and receive and execute commands (as service requests) from those information systems. This provides an access point that crosses the threat surface around those information systems; to the degree that those IoT devices are not secure, that access point is not secure. IoT devices typically have minimal security features built in; their data and command streams can be easily hacked, and quite often, IoT devices have no built-in capabilities for updating firmware, software, or control parameters. IoT devices that cannot provide strong identity authentication, participate in rigorous access control processes, or provide for secure data uplink and downlink are most vulnerable to attack, capture by a threat actor, and misuse against their owner or others. To the degree that a business depends on data generated by IoT devices or business logic implemented by IoT devices, that business is holding itself hostage to the security of those IoT devices. Businesses and organizations that allow IoT devices to upload, input, or otherwise inject commands of any kind (such as SQL queries) into their information systems have potentially put their continued existence in the hands of whomever it is that is actually operating that IoT device.

  Differentiate continuity and resilience with respect to applications and data.  Both of these related terms describe how well business processes and logic can operate correctly, safely, and securely despite the occurrence of errors, failures, or attacks by threat actors (natural or human). Continuity measures the degree to which a system can produce correct, timely results when input errors, missing data, failed or failing subsystems, or other problems are impacting its operations. Designed-in redundancy of critical paths or components can provide a degree of graceful degradation—as elements fail or as system resources become exhausted, the system may provide lower throughput rates, produce more frequent but tolerable errors, or stop executing noncritical functions to conserve its capabilities to fulfill mission-essential tasks. Cloud-based systems might slow down dispatching new instances of VMs to support customer-facing tasks, for example, when there aren't enough resources to allow new VMs to run efficiently; this might slow the rate of dealing with new customer requests in favor of completing ongoing transactions. Resiliency measures the ability of the system to deal with unanticipated errors or conditions without crashing or causing unacceptable data loss or business process interruption. Auto-save and versioning capabilities on a word processor application, for example, provide resiliency to an author in two ways. Auto-save protects against an unplanned system shutdown (such as inadvertently unplugging its power cord); at most, the user/author loses what was typed in since the last automatic save. Versioning protects against the off chance that users make modifications, save the file, and then realize that they need to undo those modifications.

  Describe common vulnerabilities in applications and data, as well as common ways attackers can exploit them.  Almost all applications are built to need and use three broad classes of input data: commands that select options and features, control parameters for features and options, and end-user data for processing by the application itself. Errors or deficiencies in program design will quite frequently result in exploitable vulnerabilities that allow attackers to select a series of operations, disrupt the application with badly formed data, or otherwise outthink the application's designer and subvert its execution to suit the needs of their attack. Such exploits can allow the attacker to obtain unauthorized resource and information access, elevate their privilege state, cause a disruption of service, or any combination of those. The most common vulnerabilities in applications software are those that relate to incomplete or inadequate validation of all data input to the program, whether from command line parameters, files, or user input via screens, fields, forms, or other means. Out-of-limits attacks attempt to discover and exploit the lack of rigorous, resilient exception handling logic—extra programming in which the designer anticipated out-of-bounds inputs by building in the logic to handle them in resilient ways. Without such resilience designed in, most applications programs will fail to execute properly, generate abnormal results, or cause other systems problems. This may lead to loss of data (in memory or in files stored on disk) or corruption of stored data, or in some cases cause the program to mistakenly execute the bad data as if it was a series of computer instructions. Input of numbers that lead to arithmetic faults, such as an attempt to divide by zero, may also cause an application to be terminated by the operating system, unless the application's programmer has built in logic to check for such conditions and handle them safely. Buffer overflow attacks attempt to input data that exceeds the designed-in maximum length or size for an input field or value, which can cause the program's runtime system to attempt to execute the overflowing data as if it were a series of legitimate instructions. SQL injection, for example, occurs when an attacker inputs a string of SQL commands rather than a set of text or other data, in ways that cause the application to pass that input to its underlying database engine to execute as if it were an otherwise legitimate, designed-in query. Inadequate user authentication vulnerabilities exist when the application program does not properly authenticate the user or subject that is asking for service from the application, and through that service, access to other information resources. For example, a typical word processing program should not (normally) be allowed to overwrite systems files that control the installation and operational use of other applications, or create new user accounts. Related to this are attempts by applications programmers to take programming shortcuts with secure storage of user or subject credentials (such as storing credit card numbers in clear text “temporarily” while using them). Data dump attacks attempt to cause the application to terminate abnormally might result in a diagnostic display of data (a “postmortem dump”) from which the attacker can extract exploitable information. Backdoor attacks attempt to make use of built-in diagnostic, maintenance, or test features in the application, which may be misused to violate access privileges to in-memory or other data, or to modify the application to have it include otherwise unauthorized sets of instructions or control parameters.

  Many modern applications depend on code injection to provide runtime tailoring of features, control parameters, and other user-related or system-related installation features; Windows systems use dynamic link library (DLL) files for this. One example of a Trojan horse attack exploits an application's failure to validate the correctness of a DLL or other code injection, thus allowing attackers to embed their own logic within the application. Related to these are input data file Trojan horse attacks, in which attackers first exploit other systems vulnerabilities to replace legitimate and expected input files or data streams with their own data. For example, adding false transactions to a backup data set, and then triggering an abnormal application termination, could cause the system to process those transactions without detecting or flagging an error condition—such as transferring money between two accounts, even if one of them isn't legitimate.

• Describe the common countermeasures to prevent or limit the damage from common attacks against data and applications.  In a nutshell, constant vigilance is the best defense. First, protect the software base itself—the applications, their builds, and installations files and logs, control parameter files, and other key elements. Stay informed as to reported vulnerabilities in your applications, keep the software updated with the latest security fixes and patches, and develop procedural workarounds to protect against reported vulnerabilities that might impact your business but for which the vendor has not yet released a fix. This would include procedural steps to reduce (or prevent) out-of-limits data input—after all, most out-of-limits data that might cause the application to behave abnormally is probably not data that makes business sense in your business processes or logic! Next, protect the data—what you already have and use, and each new input that you gather. Institute data quality and data assurance processes, with which you define each data item, its limits, and the constraints on its use within your business logic. Implement data quality review, inspection, and audit processes to help detect and characterize bad data already in your systems. Ensure that identity management, access control, authorization, accounting, and audit systems are properly configured and in use. Monitor and review usage logs to detect possible anomalies in usage, access attempts, execution, or termination. Finally, and perhaps most important, train and educate your users so that they know what reasonable and expected systems and applications behavior is and thus recognize that anything else is abnormal and perhaps suspicious.

  Explain ways to address the security issues of shared storage.  Shared storage systems typically provide information storage, access, retrieval, archive, backup, and restore services for many different customer organizations. Each customer must have confidence that other customers and the storage provider cannot read, modify, or extract its information without its knowledge and consent. To meet the combined confidentiality, integrity, and availability needs of all of its customers, the storage system provider must be able to prevent any customer information from being accessed or modified by any other customer or by processes invoked by another customer. These protections should also be extended to customer's access histories, transaction logs, deleted files, or other information regarding the customer's use of its own data. Storage providers frequently have to replace failed or failing storage media, such as disk drives, and this should not lead to compromise of customer data written on that (discarded) media. Storage providers can meet these obligations by encrypting files and file directories for each customer, by striping or segmenting storage of data and directories across multiple physical storage media, and by using virtual file systems (which migrate files or directory trees to faster or slower storage media to meet frequent usage demands). End-user customer organizations can also use directory-level and file-level encryption to add an extra layer of protection. In many cases, storage providers and end-user customer organizations can also use integrated resource, access, and identity management systems, such as Microsoft Active Directory, to define, deploy, and manage their information assets in more secure, auditable, and verifiable ways.

Review Questions

1. Which statements best explain why applications programs have exploitable vulnerabilities in them? (Choose all that are correct.)
   1. Commercial software companies rush their products to market and pay little attention to designing or testing for security.
   2. In-house developers often do not rigorously use design frameworks and coding standards that promote or enforce secure programming.
   3. End users write most of the real applications that businesses use, but without configuration management, they're impossible to update and keep secure.
   4. Most users do not keep their software updated, so they are missing out on security patches.
2. Why is allowed listing a better approach to applications security than blocked listing? Choose the most correct statement.
   1. Allowed listing depends on government-certified lists of trusted software providers, whereas blocked listing needs to recognize patterns of malicious code behavior, or malware signatures, to block the malware from being installed and executed.
   2. For most organizations, the list of applications they have chosen to trust is far smaller and easier to administer than huge lists of malware signatures and behavioral models.
   3. Administering an allowed listing system can require a lot of effort, but when an unknown program is trying to execute (or be installed), you know it is not yet trusted and can prevent harm.
   4. With blocked listing only, new malware may not be recognized as such before it installs, executes, and begins to harm your systems and information.
3. What is the role of threat modeling when an organization is planning to migrate its business processes into a cloud-hosted environment? Choose the most correct statement.
   1. Private cloud deployments should see no change in threat modeling or threat surfaces.
   2. Migrating to the cloud may not change the logical relationship between information assets and subjects requesting to use them, or the way privileges are set based on roles, needs, and trust, but the connection path to them may change; this probably changes the threat surface.
   3. This really depends on the choice of IaaS, SaaS, or PaaS service models.
   4. Shared responsibility models will transfer much of the organization's needs for information security services to the cloud-hosting provider, and they will apply their standard threat models to the chosen service and deployment models
4. “Maintaining or improving information security while migrating to the clouds is more of a contractual than technical problem to solve.” Which statement best shows why this is either true or false?
   1. It is false. The contractual side is similar to any other service provider relationship and is done once; the technical challenge of mastering a whole new set of features and capabilities is far larger and is always ongoing.
   2. It is true. Cloud service models are constantly changing, and this means that the contracts, terms of service, or service level agreements are continually being updated. The underlying software technologies, however, don't change as much or as frequently.
   3. It is false. The contractual agreements do change quite frequently as the underlying technologies, threats, and business case for both the cloud host and the customer change with time. These changes cause about equal amounts of work on both administrative and technical elements of the customer organization.
   4. It is false. The contractual agreements do change quite frequently as the underlying technologies, threats, and business case for both the cloud host and the customer change with time. However, even these changes cause less work, less frequently, for the administrative elements and more for the technical elements of the typical customer organization.
5. Fred is on the IT team migrating his company's business systems into a public cloud provider, which will host the company's processes and data on its datacenters in three different countries to provide load balancing, failover/restart, and backup and restore capabilities. Which statement or statements best addresses key legal and regulatory concerns about this plan? (Choose all that apply.)
   1. Because Fred's company does not have a business office or presence in the countries where the cloud host's datacenters are, those countries do not have legal or regulatory jurisdiction over company data.
   2. The countries where the cloud host's datacenters are located, plus all of the countries in which Fred's company has a business presence, office, or other facility, have jurisdiction over company data.
   3. In addition to staying compliant with all of those different countries' laws and regulations, Fred's company must also ensure that it does not violate cultural, religious, or political taboos in any of those countries.
   4. These jurisdictional arguments only apply to data stored on servers or systems within a given country, or that is being used in that country; nations do not control the movement of data across their borders.
6. Many issues are involved when planning for a third party to perform services involving data storage, backup and restore, and destruction or processing services for your company. Which of the following statements is not correct with regard to such planning or to your actual conduct of operations with that third party? (Choose all that apply.)
   1. Your data protection responsibilities remain with you; you need to be able to actively verify that such third parties are doing what you've contracted with them to do. Otherwise, you are blindly trusting them.
   2. Your contracts with these third parties should use a shared responsibility model to clearly delineate which party has which responsibilities; this will, in most cases, hold you harmless when the third party goes outside of the contract
   3. Since third parties are by definition on a contract with you, as your subcontractor, you are not liable or responsible for mistakes they make in performing their duties.
   4. What your third party providers, subcontractors, or employees (for that matter) do in your name and in your service, you are ultimately responsible for.
7. Which statements about the role(s) of archiving, backup, and restore in meeting information security needs are most correct? (Choose all that apply.)
   1. These each contribute to availability in similar ways.
   2. These each contribute to availability and nonrepudiation.
   3. As part of an incident response or disaster recovery plan, prompt restore to a known good data configuration may prevent other data from being compromised or breached, thus contributing to confidentiality.
   4. These have no role to play in achieving authentication needs.
8. How does securing a virtual machine differ from securing a physical computer system? (Choose all that apply.)
   1. The basic tasks of defining the needs, configuring system capabilities in support of those needs, and then operationally deploying the VM are conceptually the same as when deploying the same OS and apps on a desktop or laptop. You use many of the same tools, OS features, and utilities.
   2. VMs cannot run without some kind of software-defined network and a hypervisor, which bring many more complex security concerns that administrators need to deal with to achieve required information security performance.
   3. VMs can access any resource on the bare metal machine that is hosting them through the hypervisor, which requires administrators to take many extra precautions to prevent security breaches.
   4. The bare metal server, host OS (if used), and hypervisor provide none of the security features you'll need to configure to keep other system users, processes, and data, and those in each VM, safe, secure, and protected from each other.
9. Why is endpoint security so important to an organization?
   1. Users, who interact with organizational IT infrastructures and information at the endpoints, are notoriously difficult to control; if we can better control and secure the endpoints themselves, then we can prevent most end user–introduced security problems.
   2. Endpoints are where information turns into action, and that action produces value; on the way into the system, it is where action produces valuable information. This is where business actually gets done and work accomplished. Without the endpoints, the system is meaningless.
   3. Endpoints are what most users and customers see, and if endpoints are not secure, users and customers will not engage with our security programs and help us keep the system safe.
   4. While endpoints are where many users do information work, organizational managers and leaders draw their decision support at the systems level, and not from an endpoint device such as a smartphone. Data quality and software quality processes need to ensure that once data enters the system from an endpoint, it is then protected to meet CIANA+PS needs throughout its life.
10. Jayne's company is considering the use of IoT devices as part of its buildings, grounds, and facilities maintenance tasks. Which statements give Jayne sound advice to consider for this project?
    1. Since IoT devices can easily be configured, updated, or patched, they are just as capable of being secure as are laptops, desktops, or smartphones.
    2. Functions that change frequently are well suited to IoT devices.
    3. Typical IoT devices are best suited to use where security or human safety are a primary concern.
    4. It may be better to consider industrial process control modules, rather than IoT devices, to interact with machinery, such as pumps and landscaping equipment.
11. Which statements about continuity and resilience are correct? (Choose all that apply.)
    1. Continuity measures a system's ability to deal with events the designers didn't anticipate.
    2. Continuity and resilience are basically the same idea, since they both deal with how systems handle errors, component or subsystem failures, or abnormal operational commands from users or other system elements.
    3. Resilience measures a system's ability to tolerate events or conditions not anticipated by the designers.
    4. Continuity measures a system's ability to deal with out-of-limits conditions, component or subsystems failures, or abnormal operating commands from users or other system elements, by means of designed-in redundancy, load shedding, or other strategies.
12. In which phase or phases of a typical data exfiltration attack would a hacker be making use of phishing? (Choose all that apply.)
    1. Reconnaissance and characterization
    2. Data gathering, clumping, masking, and aggregating
    3. Installing and using covert command and control capabilities
    4. Initial access
13. What are some effective, practical strategies to detect data exfiltration attacks? (Choose all that apply.)
    1. Analyze access control and resource usage log data to alert when abnormal patterns of behavior are noted.
    2. Alert when failed attempts to access a resource (whether it is protected by encryption or not) exceed a specified limit.
    3. Use digital rights management in addition to other identity management and access control capabilities.
    4. Set filters and rules on network traffic, inspecting suspicious packets, streams, or addresses to check for data being exfiltrated.
14. Which statement about privacy and data protection is most correct?
    1. International standards and agreements specify that personally identifiable information (PII) and information about an individual's healthcare, education, and work or credit history must be protected from unauthorized use or disclosure.
    2. Some countries, or regions like the EU, have laws and regulations that specify how personally identifiable information (PII) and information about an individual's healthcare, education, and work or credit history must be protected from unauthorized use or disclosure. Other countries do not. It's up to the organization that gathers, produces, uses, or disposes of such private data to determine what protection, if any, is needed.
    3. Storing backup or archive copies of privacy-related information in a datacenter in another country, without doing any processing there, does not subject you to that country's data protection laws.
    4. Sometimes, it seems cheaper to run the risk of fines or loss of business from a data breach involving privacy-related data than to implement proper data protection to prevent such a loss. Although this might make financial sense, it is not legal or ethical to do so.
15. The “garbage-in, garbage-out” (GIGO) problem means:
    1. Noise on power supplies or signal cables can corrupt data in motion, which if processed can result in abnormal or incorrect “garbage” results.
    2. Most information processes involve a set of related data items that represent or model a real person, activity, or part of the world. When that set of data is mutually inconsistent, or inconsistent with other data on hand about that real entity, each field may be within range but the overall meaning of the data set is corrupt. This “garbage,” when processed (as input) by apps, produces equally meaningless but valid-looking outputs.
    3. Organizations that just throw away damaged storage devices; printed copies of their data, application source code, design notes; and so forth are putting this “garbage” right where a “dumpster diver” hacker attack can collect it, examine it, and possibly find exploitable vulnerabilities.
    4. Data input attacks can cause some applications to abort or execute abnormally, sometimes in ways that allow the garbage data that was input to be executed as if it is command strings or machine language instructions.
16. Which of the following might be serious example(s) of “shadow IT” contributing to an information security problem? (Choose all that apply.)
    1. One user defines a format or style sheet for specific types of documents that other users will create and manage.
    2. An end user writes special-purpose database queries and reports used to forecast sales and project production and inventory needs, which are reviewed and used at weekly division meetings.
    3. Several users build scripts, flows, and other processing logic to implement a customer service help desk/trouble ticket system, using its own database on a shared use/collaboration platform that the company uses.
    4. Users post documents, spreadsheets, and many other types of information on a company-provided shared storage system, making the information more freely available throughout the company.
17. Sandi has suggested to her boss that their small company should be using a cloud-based shared storage service, such as OneDrive, Dropbox, or Google Drive. Her boss believes these are inherently insecure. Which of the following statements would not help Sandi make her case?
    1. Check the reputation and business model of the shared storage providers; check what national/legal jurisdiction they operate in, compared to the one her business operates in.
    2. Examine their stated, posted privacy and security policies; ask for a sample contract, terms of reference, or service level agreement, and see if they claim to provide what her company needs.
    3. Sandi can always encrypt her files before moving them into storage; that way, even if another user, a hacker, or the provider themselves try to read the file, they can't.
    4. Sandi can take advantage of a free trial offer and see if her information security staff can hack into other users' storage or into system logs and account information on the provider. If her “white hats” can't break in and peek, the system is safe enough for her.
18. Your boss tells you that securing the endpoints should consider all of the measures you would use to secure the information infrastructures themselves. Is she correct? Which statement best confirms or refutes her statement?
    1. False. Many of the things we do to secure operating systems and networks, for example, just don't apply to an endpoint device, the apps on it, and the user's interactions with it.
    2. True. After all, each endpoint is (by definition) embedded in or part of one or more threat surfaces; from there, the same threat modeling and assessment processes will lead us through the same risk management and mitigation processes, with choices tailored as needed.
    3. True. All of the same risk management, vulnerability assessment, risk mitigation, and operational risk management processes apply to each node of our system and to the system as a whole, tailored to the specific risks, vulnerabilities, technologies, and operational needs.
    4. False. What happens at the endpoints is a special case of information security and needs special attention that is very different than how we assess risk to servers, networks, or applications platforms.
19. What steps can you take to limit or prevent attacks on your systems that attempt to spoof, corrupt, or tamper with data? (Choose all that apply.)
    1. Ensure that firewalls, routers, and other network infrastructures filter for and block attempts to access network storage without authorization.
    2. Develop and use an organizational data model and data dictionary that contain all data-focused business logic; use them to build and validate business processes and the apps that support them.
    3. Implement data quality processes that ensure all data is fit for all purposes, in accordance with approved business logic.
    4. Implement information classification, and use access control and identity management to enforce it.
20. Your coworkers don't agree with you when you say that data quality is a fundamental part of information security. Which of the following lines of argument are true in the context of your discussion with them? (Choose all that apply.)
    1. If our business logic doesn't establish the data quality rules and constraints, we have no idea if an input or a whole set of inputs makes valid business sense or is a spoof attack trying to subvert our systems.
    2. Since we don't have a data quality program now, if we get served with a digital discovery order, who knows whether the data we surrender to the authorities is correct and complete? The attorneys might care, but that really has no effect on us.
    3. We have users who complain that when they try to test and evaluate backup data sets, the backup data makes no sense. If a real disruption or disaster strikes, and our backups don't make any business sense, we could be out of business pretty quickly.
    4. We mitigate information risk to achieve the CIANA+PS needs that the business impact analysis and the risk management plan called for; since those high-level plans didn't conclude that we need a data quality program, then we probably don't.