Understand, Adhere to, and Promote Professional Ethics

Let’s start with what it means to be a professional: It means that society has placed great trust and confidence in you, because you have been willing to take on the responsibility to get things done right. Society trusts in you to know your practice, know its practical limits, and work to make sure that the services you perform meet or exceed the best practices of the profession. This is a legal and an ethical responsibility.

Everything you do requires you to understand the needs of your employers or clients. You listen, observe, gather data, and ask questions; you think about what you’ve learned, and you come to conclusions. You make recommendations, offer advice, or take action within the scope of your job and responsibilities. Sometimes you take action outside of that scope, going above and beyond the call of those duties. You do this because you are a professional. You would not even think of making those conclusions or taking those actions if they violently conflicted with what known technical standards or recognized best technical practice said was required. You would not knowingly recommend or act to violate the law. Your professional ethics are no different. They are a set of standards that are both constraints and freedoms that you use to inform, shape, and then test your conclusions and decisions with before you act.

As a professional—in any profession—you learned what that profession requires of you through education, training, and on-the-job experience. You learned from teachers, mentors, trainers, and the people working alongside of you. They shared their hard-earned insight and knowledge with you, as their part of promoting the profession you had in common. In doing so they strengthened the practice of the ethics of the profession, as well as the practice of its technical disciplines.

(ISC)² Code of Ethics

(ISC)² provides a Code of Ethics, and to be an SSCP, you agree to abide by it. It is short and simple. It starts with a preamble, which is quoted here in its entirety:

The safety and welfare of society and the common good, duty to our principals, and to each other, requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior.

Therefore, strict adherence to this Code is a condition of certification.

Let’s operationalize that preamble—take it apart, step-by-step, and see what it really asks of us.

• Safety and welfare of society: Allowing information systems to come to harm because of the failure of their security systems or controls can lead to damage to property or injury or death of people who were depending upon those systems operating correctly.
• The common good: All of us benefit when our critical infrastructures, providing common services that we all depend upon, work correctly and reliably.
• Duty to our principals: Our duties to those we regard as leaders, rulers, or our supervisors in any capacity.
• Our duty to each other: To our fellow SSCPs, others in our profession, and to others in our neighborhood and society at large.
• Adhere and be seen to adhere to: Behave correctly and set the example for others to follow. Be visible in performing your job ethically (in adherence with this code) so that others can have confidence in us as a profession and learn from our example.

The code is equally short, containing just four canons or principles to abide by.

Protect society, the common good, necessary public trust and confidence, and the infrastructure.

Act honorably, honestly, justly, responsibly, and legally.

Provide diligent and competent service to principals.

Advance and protect the profession.

The canons do more than just restate the preamble’s two points. They show you how to adhere to the preamble. You must take action to protect what you value; that action should be done with honor, honesty, and with justice as your guide. Due care and due diligence are what you owe to those you work for (including the customers of the businesses that employ us!).

The final canon talks to your continued responsibility to grow as a professional. You are on a never-ending journey of learning and discovery; each day brings an opportunity to make the profession of information security stronger and more effective. You as an SSCP are a member of a worldwide community of practice—the informal grouping of people concerned with the safety, security, and reliability of information systems and the information infrastructures of the modern world.

In ancient history, there were only three professions—those of medicine, the military, and the clergy. Each had in its own way the power of life and death of individuals or societies in its hands. Each as a result had a significant burden to be the best at fulfilling the duties of that profession. Individuals felt the calling to fulfill a sense of duty and service, to something larger than themselves, and responded to that calling by becoming a member of a profession.

This, too, is part of being an SSCP. Visit https://www.isc2.org for more information.

Organizational Code of Ethics

Most businesses and nonprofit or other types of organizations have a code of ethics that they use to shape their policies and guide them in making decisions, setting goals, and taking actions. They also use these codes of ethics to guide the efforts of their employees, team members, and associates; in many cases, these codes can be the basis of decisions to admonish, discipline, or terminate their relationship with an employee. In most cases, organizational codes of ethics are also extended to the partners, customers, or clients that the organization chooses to do business with. Sometimes expressed as values or statements of principles, these codes of ethics may be in written form, established as policy directives upon all who work there; sometimes, they are implicitly or tacitly understood as part of the organizational culture or shaped and driven by key personalities in the organization. But just because they aren’t written down doesn’t mean that an ethical code or framework for that organization doesn’t exist.

Fundamentally, these codes of ethics have the capacity to balance the conflicting needs of law and regulation with the bottom-line pressure to survive and flourish as an organization. This is the real purpose of an organizational ethical code. Unfortunately, many organizations let the balance go too far toward the bottom-line set of values and take shortcuts; they compromise their ethics, often end up compromising their legal or regulatory responsibilities, and end up applying their codes of ethics loosely if at all. As a case in point, consider that risk management must include the dilemma that sometimes there are more laws and regulations than any business can possibly afford to comply with and they all conflict with each other in some way, shape, or form. What’s a chief executive or a board of directors to do in such a circumstance?

It’s actually quite easy to incorporate professional and personal ethics, along with the organization’s own code of ethics, into every decision process you use. Strengths, weaknesses, opportunities, and threats (SWOT) analyses, for example, focus your attention on the strengths, weaknesses, opportunities, and threats that a situation or a problem presents; being true to one’s ethics should be a strength in such a context, and if it starts to be seen as a weakness or a threat, that’s a danger signal you must address or take to management and leadership. Cost/benefits analyses or decision trees present the same opportunity to include what sometimes is called the New York Times or the Guardian test: How would each possible decision look if it appeared as a headline on such newspapers of record? Closer to home, think about the responses you might get if you asked your parents, family, or closest friends for advice about such thorny problems—or their reactions if they heard about it via their social media channels. Make these thoughts a habit; that’s part of the practice aspect of being a professional.

As the on-scene information security professional, you’ll be the one who most likely has the first clear opportunity to look at an IT security posture, policy, control, or action, and challenge any aspects of it that you think might conflict with the organization’s code of ethics, the (ISC)² Code of Ethics, or your own personal and professional ethics.

Conceptual Models for Information Security

There are any number of frameworks, often represented by their acronyms, which are used throughout the world to talk about information security. All are useful, but some are more useful than others.

• The CIA triad (sometimes written as CIA) combines confidentiality, integrity, and availability and dates from work being done in the 1960s to develop theoretical models for information systems security and then implement those technologies into operating systems, applications programs, and communications and network systems.
• CIANA combines confidentiality, integrity, availability, nonrepudiation, and authentication. It reflects a greater emphasis starting in the 1980s on legal and regulatory compliance issues. It also reflects recognition by military and intelligence communities for more fundamental support, at the infrastructure levels, for systems that cannot easily be spoofed by unauthorized messages inserted into them. The greater emphasis on nonrepudiation and authentication also provides a much stronger foundation for both criminal and civil law to be able to ascertain what actions were taken, by whom, and when, in the context of an incident, dispute, or conflicting claims of ownership or authorship.
• The Parkerian hexad includes confidentiality, integrity, availability, authenticity, utility, and possession or control.

These frameworks, and many more, have their advocates, their user base, and their value. That said, in the interest of consistency, we’ll focus throughout this book on CIANA, as its emphasis on both nonrepudiation and authentication have perhaps the strongest and most obvious connections to the vitally important needs of e-commerce and our e-society to be able to conduct personal activities, private business, and governance activities in ways that are safe, respectful of individual rights, responsible, trustworthy, reliable, and transparent.

It’s important to keep in mind that these attributes of systems performance or effectiveness build upon each other to produce the overall degree of trust and confidence we can rightly place on those systems and the information they produce for us. We rely on high-reliability systems because their information is correct and complete (high integrity), it’s where we need it when we need it (availability), and we know it’s been kept safe from unauthorized disclosure (it has authentic confidentiality), while at the same time we have confidence that the only processes or people who’ve created or modified it are trusted ones. Our whole sense of “can we trust the system and what it’s telling us” is a greater conclusion than just the sum of the individual CIANA, Parkerian, or triad attributes.

Let’s look further at some of these attributes of information security.

Confidentiality

Often thought of as “keeping secrets,” confidentiality is actually about sharing secrets. Confidentiality is both a legal and ethical concept about privileged communications or privileged information. Privileged information is information you have, own, or create, and that you share with someone else with the agreement that they cannot share that knowledge with anyone else without your consent or without due process in law. You place your trust and confidence in that other person’s adherence to that agreement. Relationships between professionals and their clients, such as the doctor-patient or attorney-client ones, are prime examples of this privilege in action. In rare exceptions, courts cannot compel parties in a privileged relationship to violate that privilege and disclose what was shared in confidence.

Confidentiality refers to how much we can trust that the information we’re about to use to make a decision with has not been seen by unauthorized people. The term unauthorized people generally refers to any person or any group of people who could learn something from our confidential information and then use that new knowledge in ways that would thwart our plans to attain our objectives or cause us other harm.

Confidentiality needs dictate who can read specific information or files or who can download or copy them; this is significantly different from who can modify, create, or delete those files.

One way to think about this is that integrity violations change what we think we know; confidentiality violations tell others what we think is our private knowledge.

Business has many categories of information and ideas that it needs to treat as confidential, such as the following:

• Proprietary, or company-owned information, whether or not protected by patent, copyright, or trade secret laws
• Proprietary or confidential information belonging to others but shared with the company under the terms of a nondisclosure agreement (NDA)
• Company private data, which can include business plans, budgets, risk assessments, and even organizational directories and alignments of people to responsibilities
• Data required by law or regulation to be kept private or confidential
• Privacy-related information pertaining to individual employees, customers, prospective customers or employees, or members of the public who contact the firm for any reason
• Customer transaction and business history data, including the company’s credit ratings and terms for a given customer
• Customer complaints, service requests, or suggestions for product or service improvements

In many respects, such business confidential information either represents the results of investments the organization has already made or provides insight that informs decisions they’re about to make; either way, all of this and more represent competitive advantage to the company. Letting this information be disclosed to unauthorized persons, inside or outside of the right circles within the company, threatens to reduce the value of those investments and the future return on those investments. It could, in the extreme, put the company out of business!

Let’s look a bit closer at how to defend such information.

Integrity

Integrity, in the common sense of the word, means that something is whole, complete, its parts smoothly joined together. People with high personal integrity are ones whose actions and words consistently demonstrate the same set of ethical principles. Having such integrity, you know you can count on them and trust them to act both in ways they have told you they would and in ways consistent with what they’ve done before.

When talking about information systems, integrity refers to both the information in them and the processes (that are integral to that system) that provide the functions we perform on that information. Both of these—the information and the processes—must be complete, correct, function together correctly, and do so in reliable, repeatable, and deterministic ways for the overall system to have integrity.

When we measure or assess information systems integrity, therefore, we can think of it in several ways.

• Binary: Either our information system has integrity or it does not. We can rely upon it or we cannot.
• Threshold-based: Our information system has at least a minimum level of systems and information integrity to function reliably but possibly in a degraded way, either with higher than desired (but still acceptable) error rates or at reduced transaction throughput or volume levels.

Note that in all but the simplest of business or organizational architectures, you’ll find multiple sets of business logic and therefore business processes that interact with each other throughout overlapping cycles of processing. Some of these lines of business can function independently of each other, for a while, so long as the information and information systems that serve that line of business directly are working correctly (that is, have high enough levels of integrity).

• Retail online sales systems have customer-facing processes to inform customers about products, services, and special offers. Their shopping cart systems interact with merchandise catalog databases, as well as with order completion, payment processing, and order fulfillment. Customer sales order processing and fulfillment can occur—with high integrity—even though other systems that update the catalogs to reflect new products or services or bring new vendors and new product lines into the online store are not available.
• Computer-aided manufacturing systems have to control the flow of materials, parts, subassemblies, and finished products on the factory floor, interacting with logistics and warehousing functions on both the input and output sides of the assembly line. These systems are typically not tightly coupled with the functions of other business elements, such as finance, sales and marketing, or personnel management, even though at some point the assembly line grinds to a halt if finance hasn’t paid the bills to suppliers in a timely way.

Integrity applies to three major elements of any information-centric set of processes: to the people who run and use them, to the data that the people need to use, and to the systems or tools that store, retrieve, manipulate, and share that data. Note, too, that many people in the IT and systems world talk about “what we know” in four very different but strongly related ways, sometimes referred to as D-I-K-W.

• Data consists of the individual facts, observations, or elements of a measurement, such as a person’s name or their residential address.
• Information results when you process data in various ways; information is data plus conclusions or inferences.
• Knowledge is a set of broader, more general conclusions or principles that you’ve derived from lots of information.
• Wisdom is (arguably) the insightful application of knowledge; it is the “a-ha!” moment in which you recognize a new and powerful insight that you can apply to solve problems with or take advantage of a new opportunity—or to resist the temptation to try!

Figure 2.1 illustrates this knowledge pyramid.

Professional opinion in the IT and information systems world is strongly divided about data versus DIKW, with about equal numbers of people holding that they are the same ideas, that they are different, and that the whole debate is unnecessary. As an information security professional, you’ll be expected to combine experience, training, and the data you’re observing from systems and people in real time to know whether an incident of interest is about to become a security issue, whether your organization uses knowledge management terminology like this or not. This is yet another example of just how many potentially conflicting, fuzzy viewpoints exist in IT and information security.

Availability

Is the data there when we need it in a form we can use?

We make decisions based on information; whether that is new information we have gathered (via our data acquisition systems) or knowledge and information we have in our memory, it’s obvious that if the information is not where we need it when we need it, we cannot make as good a decision as we might need.

• The information might be in our files, but if we cannot retrieve it, organize it, and display it in ways that inform the decision, then the information isn’t available.
• If the information has been deleted, by accident, sabotage, or systems failure, then it’s not available to inform the decision.

Those might seem obvious, and they are. Key to availability requirements is that they specify what information is needed; where it will need to be displayed, presented, or put in front of the decision-makers; and within what span of time the data is both available (displayed to the decision-makers) and meaningful. Yesterday’s data may not be what we need to make today’s decision.

Note that availability means something different for a system than it does for the information the system produces for us. Systems availability is measurable, such as via a percentage of capacity or a throughput rate. Information availability, by contrast, tells us one of three things.

• Yes, we have what we need to know to make this decision or take this action.
• No, we do not have what we need to know, so we have to decide blindly.
• We have some of what we need to know, and we cannot logically infer that what’s missing won’t cause our decision to be wrong and lead us to harm.

Accountability

Information and information systems represent significant investments by organizations, and as a result, there’s a strong bottom-line financial need to know that such investments are paying off—and that their value is not being diluted due to loss of control of that information (via a data breach or exfiltration) or loss or damage to the data’s integrity or utility. Organizations have three functional or operational needs for information regarding accountability. First, they gather information about the use of corporate information and IT systems. Then they consolidate, analyze, and audit that usage information. Finally, they use the results of those reviews to inform decision-making. Due diligence needs, for example, are addressed by resource chargeback, which attributes the per-usage costs of information to each internal user organization. Individuals must also be held accountable for their own actions, including their use or misuse of corporate information systems. Surrounding all of this is the need to know whether the organization’s information security systems are actually working correctly and that alarms are being properly attended to.

Privacy

Although legal and cultural definitions of privacy abound, we each have an internalized, working idea of what it means to keep something private. Fundamentally, this means that when we do something, write something down, or talk with another person, we have a reasonable expectation that what is said and done stays within a space and a place that we can control. We get to choose whom we share our thoughts with or whom we invite into our home. And with this working concept of privacy deep in our minds, we establish circles of trust. The innermost circle, those closest to us, we call our intimates; these are the people with whom we mutually share our feelings, ideas, hopes, worries, and dreams. Layer by layer, we add on other members of our extended family, our neighbors, or even people we meet every morning at the bus stop. We know these people to varying degrees, and our trust and confidence in them varies as well. We’re willing to let our intimates make value judgments about what we consider to be our private matters or accept criticism from them about such matters; we don’t share these with those not in our “inner circle,” and we simply not tolerate them (tolerate criticism or judgments) from someone who is not at the same level of trust and regard.

Businesses work the same way. Businesses need to have a reasonable expectation that problems or issues stay within the set of people within the company who need to be aware of them and involved in their resolution. This is in addition to the concept of business confidential or proprietary information—it’s the need to take reasonable and prudent measures to keep conversations and tacit knowledge inside the walls of the business and, when applicable, within select circles of people inside the business.

Nonrepudiation

The fundamental design of the earliest internetworking protocols meant that, in many cases, the sender had no concrete proof that the recipient actually received what was sent. Contrast this with postal systems worldwide, which have long used the concept of registered mail to verify to the sender that the recipient or his agent signed for and received the piece of mail on a given date and time. Legal systems have relied for centuries on formally specified ways to serve process upon someone. Both of these mechanisms protect the sender’s or originator’s rights and the recipient’s rights: Both parties have a vested interest in not being surprised by claims by the other that something wasn’t sent, wasn’t done, or wasn’t received. This is the basis of the concept of nonrepudiation, which is the aspect of a system that prevents a party or user from denying that they took an action, sent a message, or received a message. Nonrepudiation does not say that the recipient understood what you sent or that they agreed with it, only that they received it.

Email systems have been notorious for not providing reliable confirmation of delivery and receipt. Every email system has features built into it that allow senders and server administrators to control whether read receipts or delivery confirmations work reliably or correctly. Email threads can easily be edited to show almost anything in terms of sender and recipient information; attachments to emails can be modified as well. In short, off-the-shelf email systems do not provide anything that a court of law or an employment relations tribunal will accept as proof of what an email user claims it is.

Business cannot function that way. The transition from postal delivery of paper to electronic delivery of transactions brought many of the same requirements for nonrepudiation into your web-enabled e-business systems. What e-business and e-commerce did not do a very good job of was bringing that same need for nonrepudiation to email.

There are a number of commercial products that act as add-ons, extensions, or major enhancements to email systems that provide end-to-end, legally compliant, evidence-grade proof regarding the sending and receiving of email. A number of national postal systems around the world have started to package these systems as their own government-endorsed email version of registered postal mail. Many industry-facing vertical platforms embed these nonrepudiation features into the ways that they handle transaction processing, rendering reams of fax traffic, uncontrollable emails, or even postal mail largely obsolete.

Systems with high degrees of nonrepudiation are in essence systems that are auditable and that are restricted to users who authenticate themselves prior to each use; they also tend to be systems with strong data integrity, privacy, or confidentiality protection built into them. Using these systems improves the organization’s bottom line, while enhancing its reputation for trustworthiness and reliability.

Authentication

This element of the classic CIANA set of information security characteristics brings together many threads from all the others regarding permission to act. None of the other attributes of information security can be implemented, managed, or controlled if the system cannot unambiguously identify the person or process that is trying to take an action involving that system and any or all of its elements and then limit or control their actions to an established, restricted set. Note that the word authentication is used in two different ways.

• Information is authenticated by confirming that all of the metadata about its creation, transmission, and receipt convey that the chain of trust from creator through sender to recipient has not been violated. Authentication of a sent email or file demonstrates that it was created and sent by a known and trusted person or process. This requires that access control as a process grants permission to users or the tasks executing on their behalf to access a system’s resources, use them, change them, share them with others, or create new information assets in that system.
• In access control terms, authentication validates that the requesting subject (process or user) is who or what they claim that they are and that this identity is known to the system. Authorization then allows that authenticated identity to perform a specific set of tasks. Taken together, this is what determines whether you are using someone else’s computers or networks with their permission and approval or are trespassing upon their property.

1984 was a watershed year in public law in this regard, for in the Computer Fraud and Abuse Act (CFAA), the U.S. Congress established that entering into the intangible property that is the virtual world inside a computer system, network, or its storage subsystems was an action comparable to entering into a building or onto a piece of land. Entry onto (or into) real, tangible property without permission or authority is criminal trespass. CFAA extended that same concept to unauthorized entry into the virtual worlds of our information systems. Since then, many changes to public law in the United States and a number of other countries have expanded the list of acts considered as crimes, possibly expanding it too much in the eyes of many civil liberties watchdogs. It’s important to recognize that almost every computer crime possible has within it a violation of permissions to act or an attempt to fraudulently misrepresent the identity of a person, process, or other information system’s element, asset, or component in order to circumvent such restrictions on permitted actions. These authenticity violations are, if you would, the fundamental dishonesty, the lie behind the violation of trust that is at the heart of the crime.

Safety

Safety is that aspect of a system’s behavior that prevents failures, incorrect operational use, or incorrect data from causing damage to the system itself, to other systems it interfaces with, or to anyone else’s systems or information associated with it. More importantly, safety considerations in design and operation must ensure that humans are not subject to a risk of injury or death as a result of such system malfunctions or misuse. Note that systems designed with an explicit and inherent purpose to cause such damage, injury, or death do not violate safety considerations when they do so—so long as they only damage, destroy, injure, or kill their intended targets. The two most recent crashes of Boeing 737 Max aircraft, as of this writing, are a painful case in point. Early investigation seems to implicate the autopilot software as root or proximate cause of these crashes; and while the investigation is still ongoing, the aviation marketplace, insurance and reinsurance providers, and the flying public have already expressed their concerns in ways that have directly damaged Boeing’s bottom line as well as its reputation. Consider, too that Boeing, Airbus, and their engine and systems manufacturers have built their current generation of aircraft control systems to allow for onboard firmware and software updates via USB thumb drives while aircraft are on the airport ramp. This multiplies the risk of possibly unsafe software, or software operating with unsafe control parameters, with the risk of an inadequately tested update being applied incorrectly.

The upshot of all of this is that safety considerations are becoming much more important and influential to the overall systems engineering thought process, as the work of Dr. Nancy Leveson and others at MIT are demonstrating. Her work on the Systems Theoretic Accident Model and Process (STAMP) began in 2004 and has seen significant application in software systems reliability, resilience, and accident prevention and reduction across many industries ever since; it’s also being applied to information security in many powerful and exciting ways. Applying a safety mind-set requires you to ensure that every task involved in mitigating information security risks is done correctly—that you can validate the inputs to that task (be they hardware, software, data, or procedures) or have high confidence that they come to your hands via a trustworthy supply chain. You must further be able to validate that you’ve performed that task, installed that control or countermeasure, or taken other actions correctly and completely; you must then validate that they’re working correctly and producing the required results effectively.

Safety, like security, is an end-to-end responsibility. It’s no wonder that some cultures and languages combine both in a single word. For example, in Spanish seguridad unifies both safety and security as one integrated concept, need, and mind-set.

Key Control Principles

Several control principles must be taken into account when developing, implementing, and monitoring people-focused information security risk mitigation controls. Of these, the three most important are need to know, separation of duties, and least privilege. These basic principles are applied in different ways and with different control mechanisms. However, a solid understanding of the principles is essential to evaluating a control’s effectiveness and applicability to a particular circumstance.

Access Control and Need-to-Know

As you should expect, these key control principles of need to know, separation of duties, and least privilege also drive the ways in which you should configure and manage identity management and access control systems. Chapter 1 explored this relationship in some depth; let’s recap its key recommendations in the following list:

• Create hierarchies of groups of user identities and accounts, with privileges assigned to limit users to the least privileges they require for related tasks and functions.
• Use role-based access control as part of your strategies so that one system or user must explicitly re-authenticate as they change roles to perform more privileged sets of tasks.
• Create nonprivileged user accounts and identities for systems administrators, and others with privileged accounts, and enforce their use for tasks that do not require elevated privileges (such as email or routine web page access).
• Separate groups of user identities and accounts (for people and nonhuman elements of your systems) based on separation of duties.
• Thoroughly examine all installed software, and connections to web or cloud-hosted applications platforms to identify any instances in which apps elevate privileges for nonprivileged users who use such apps or connection. Eliminate such elevation or find ways to explicitly control and restrict it.

Job Rotation and Privilege Creep

Job rotation can be a powerful HR investment strategy that leads to increasing the knowledge and skills of a company’s workforce while improving retention of quality personnel, but these are not the concerns of the SSCP. From a security perspective, there are many reasons for creating a job rotation policy. These include reducing risks of both insider and external threats, reducing dependence on a single person (who can become a single point of failure), and increasing resiliency for business continuity and disaster recovery (BCDR) purposes. Banking and investment companies, for example, have used (and have sometimes been required by government regulators or by law) such career-broadening or rotations strategies as part of their loss control and fraud prevention mechanisms.

We cannot overstress the importance of carefully managing what should be the temporary changes in user privileges during such job rotations. Far too often, privilege creep resulting from each job rotation (temporary or permanent) ends up with the user accumulating new sets of privileges with each new task, job, or skills-broadening assignment. Over time, this can lead to an individual having far greater insight into and control over the organization’s information assets than should ever be allowed.

In practice, job rotation requires cross-training personnel for various positions and tasks within the organization. This may be within a particular business functional area or discipline, or it might involve a temporary transfer of an employee to other areas within the company. Some of the personnel in the security office, for example, might all be trained on the various roles in that office (such as log analysis, incident response, security training, or systems testing) as an intra-departmental job rotation and then learn more of the company’s human resources or product development business via a career-broadening assignment.

Job rotation helps to mitigate insider threats in several ways. It serves as a deterrent for a potentially malicious insider actually committing fraud. In cases where separation of duties would necessitate collusion, job rotation disrupts opportunities for collusion. In cases where a malicious insider has found a way to mishandle data or abuse their access, job rotation disrupts them from doing long-term damage once they’ve started. The cross-training aspect of job rotation may also aid the overall security effort by reducing the potential for employees/staff to become dissatisfied and possibly become insider threats; skilled personnel appreciate receiving additional training and challenges of new tasks, and increased training opportunities make those personnel more valuable. Increased morale of skilled personnel reduces costs because of turnover and accentuates loyalty to the organization.

Alternatives to job rotation are forced vacation or leave. The logic here is that if a malicious insider is suppressing alarms, changing or erasing audit logs, or conducting any other activity to cover their tracks or support or assist an attack, this activity should be easier to detect if the suspected insider is suddenly forced to stay away from work. During the period of mandatory vacation, that user’s account access should be suspended, and a thorough audit/review of their activity should be performed. This is especially important for those users with privileged access. For example, after the U.S. stock market crash and the collapse of its banking systems in 1929, Congressional action established not only such forced vacations but also frequent bank holidays during which banks suspended customer transaction processing while they performed extensive internal systems integrity checks; both mitigated the risks of fraud, embezzlement, and over-extension by the bank or its staff.

Another goal of job rotation is to keep malicious outsiders from being able to learn about your staff over time and trying to target or manipulate them for information or access. Reducing static patterns in personnel taskings and changing access roles repeatedly reduces the opportunity for external actors to subvert particular employees as targets.

Finally, job rotation also greatly improves the resiliency of an organization, essential in successfully executing BCDR actions. During contingency events or disasters, you must assume that some personnel will not be available/capable of performing particular tasks and functions necessary to maintain the organization’s critical processes; having other personnel not normally assigned to those functions but trained on how to perform them is a great benefit and vastly increases the likelihood of BCDR response success.

Deterrent Controls

Deterrent controls work to dissuade an attacker from initiating or continuing in their efforts to attack your systems, property, information, or people. Their design, deployment, and use should all raise either the perceived costs or risks to an attacker and the actual costs the attacker could face should they choose to persist. Guard dogs off of the leash, free to range around your property (but within a fence line), are an example of a deterrent that offers painful costs to an attacker, while raising the probability of being forcibly detained and subjected to arrest and prosecution as well.

Deterrent controls should provide a variety of capabilities to the security architect by placing barriers (real and perceived) between potential attackers and the systems they defend.

• Visible, tangible barriers, which an attacker can see, sense, or probe, signal that the target is defended.
• This suggests that the barriers are alarmed and monitored, which increases the possibility of an intrusion being detected.
• The barriers suggest to the attacker that greater assets, time, or effort must be expended for their attack to succeed.
• They also suggest that more barriers may be encountered, layer upon layer, should the attacker continue in their attempt.

Note the key concept that to be effective, a deterrent control must be visible, observable, and verifiably present to the prospective intruder. It cannot deter an attacker if the attacker doesn’t know that it is there! This directly suggests that you’re defending against a known group of attackers and that you have some degree of operational threat intelligence data, which you can use in selecting potentially effective deterrent tactics and techniques.

Simple deterrents can be physical controls, such as fences, locked doors and windows, or landscaping and paving that restricts the movement of vehicles and pedestrians onto a protected property or campus. Exterior lighting, including the use of moving spotlights or floodlights, can also provide a deterrent effect. Most physical controls are passive, in that they do not react to an intrusion attempt; active controls would include guard dogs and security controls, for example.

Physically, the architecture of buildings or workspaces make statements about an organization and the work that is performed there. These statements can also be powerful deterrents to would-be attackers. Think about how many modern embassy compounds (and not just the American ones) around the world have been transformed into little fortresses as they’ve been blast-hardened, surrounded by impact-resisting barrier walls, and armed military personnel or security guards; entry onto such embassy grounds is restricted and tightly controlled in most cases. High technology companies have also made similar architectural deterrent statements with the ways that they design, build, and operate their physical locations. These are definitely not statements of security through obscurity.

Network systems such as firewalls and intrusion detection and prevention systems can act as powerful deterrents by thwarting an attacker’s ability to gain meaningful insight via reconnaissance probes or scans. (It’s somewhat unfortunate that the line between NIDS and NIPS as product systems has become quite blurred at this point since both apply filtering rules of varying potency to block or restrict traffic from crossing their point of protection.) Well-trained, highly aware people throughout your organization are also effective deterrents when they smoothly deflect social engineering attack attempts, perhaps by guiding unknown callers through a well-rehearsed script to filter out the innocent prospective customer, client, or job seeker from the whaler-wannabee.

Preventative Controls

Preventative (or prevention) controls provide two forms of protection to keep your systems from harm by reducing the probability of an occurrence of a risk or, when it starts to occur, by containing it in such a way as to limit the spread of its disruption or damage. Securely locked doors and windows prevent an intruder from unlawfully entering your home, unless they want to elevate their risk by breaking through the locks, the windows, or the doors in question. The design of interior walls, doors, and utility spaces restricts the speed with which fire can spread from room to room, while reducing or blocking the spread of smoke and heat. This suggests that security architects should use prevention (like deterrence) in layers.

Prevention can be active or passive, as with deterrence; the same types of controls used for physical, passive deterrence also bring some prevention with them.

Host-based or network-based firewalls, intrusion detection and prevention systems, and of course identity management and access control systems are the main components of a solid prevention architecture. Layer upon layer, they detect attempts to cross a threat boundary’s controlled access points; they test that access attempt against varying sets of criteria and in some cases issue challenges requesting further credentials from the requesting subject. Since all of these systems can and should generate both accounting log information for successfully authenticated attempts, and alerts or alarms for failures, they are deterrent, prevention, and detection systems all at the same time.

Detective Controls

Detective (or detection) controls look for any out-of-limits conditions, such as signatures associated with an intrusion attempt, and then take two fundamental and important actions. First, the detection controls notify operations personnel or higher- level supervisory systems that a problem exists; this is absolutely critical if you are to have any command and control over your systems or any ability to manage an effective response to incidents as and when they occur. Second, the detection controls can (if desired) signal an attacker that you’ve noticed what they’re doing, which leads them to believe you’ll be responding to their attack. This may deter them from continuing their efforts.

All intrusion or incident detection systems are subject to error rates, as you saw in Chapter 1. Getting the crossover point set so that your risk of harm or loss due to false acceptance errors is balanced by your ongoing costs of investigating and resolving false rejections (and their concomitant “sky is falling” feeling) is a never-ending process. In fact, the smarter these controls get—and the more that they employ machine learning and predictive analytic capabilities—the more time you’ll have to invest in understanding their behavior and tuning it to fit your constantly changing threat landscape and the dynamic nature of your routine business activities.

Physical detection systems can include motion detectors, motion switches on doors and windows, and continuity circuits embedded or built into walls, fences, and other landscaping features. Many such systems can support change detection as well, which can highlight suspicious portions of the systems they surveil to human security monitors for analysis and possible action. Physical systems such as power conditioning, air and environmental conditioning systems, and other aspects of your data center or network operations facilities should be primary sources of alarms that indicate a potential disruption, possibly due to an intrusion, is underway.

Don’t forget the end-user element! Properly motivated and trained, having a cadre of end users who can spot something that’s not quite right and appreciate that management wants to hear about it sooner rather than later can often stymie an attack before it gets too far.

Corrective Controls

Corrective controls provide for the containment, isolation, or restoration of services that have been disrupted for any reason. Uninterruptible power supplies (UPSs) are a good example of this: They isolate or buffer your IT and communications systems from external commercial electrical power providers and in doing so can correct for temporary undervoltage, overvoltage, spikes, noise, or other problems with power before those problems pop circuit breakers or damage equipment. Power problems, incidentally, can also cause equipment to operate in degraded ways that are oftentimes hard to diagnose. Consumer and small business-grade routers, switches, and servers, for example, are prone to odd and intermittent outages for this reason, and the simple expedient of putting them onto an inexpensive battery backup power conditioner or UPS can save hours of fruitless troubleshooting.

Another example of a corrective control in action is when your access control system or a web page design remediates or quarantines a subject’s access request when information about that subject and that access request indicates that something is not quite right. Systems can interrogate the subject’s endpoint device, for example, to determine whether its operating system, applications, antimalware, or other functions are all properly updated, and if not, route the connection to a remediation server or page that only allows for repair actions to be taken. User subjects can also be challenged to provide further authentication credentials, if something about the time of day, the user’s geographic position, or other criteria dictate the need for enhanced vigilance.

Compensating Controls

Compensating controls are put in place when the normal, recommended, or required “best choice” of a risk mitigation control is not available or is unworkable or not affordable or when another approach has been chosen for valid reasons. Depending upon the source of the original requirement for that control, this may or may not be an issue. NIST documents, for example, tend to focus on the risk or threat to protect against, rather than attempting to specify a specific approach. (Best practices, though, often rule out approaches that are no longer useful to consider.) Another example of this can be seen in the Payment Card Industry Data Security Standard (PCI DSS), which specifies stringent security functional or performance standards by which controls must operate, as well as a formalized process for justifying the use of an alternative approach.

PCI DSS gives a good working definition of a compensating control, which can easily apply to other information risk control situations. A compensating control must do the following:

• Meet or exceed the intended level of protection as specified in the original control requirement
• Provide a level of protection that sufficiently offsets or covers the risk that the original control requirement should address
• Must provide greater levels of protection, against the total risk set that the originating or reference standard addresses, than would be achieved by the original control requirement
• Must provide a degree of overall safety and security that is commensurate with the risk of not using the recommended or required original standard in whole or in part

This can seem a bit wordy, if not confusing. An example might help. Consider PCI DSS Requirement 3.6.4, as illustrated in a white paper by Robert Schwirtz and Jeff Hall, both at RSM McGladrey. (This paper, which can be found at https://rsmus.com/pdf/understanding_pci_comp_controls.pdf, provides good insight into the thinking about compensating controls and how to ensure that a soundly reasoned, well-supported argument is made to justify their use.) This particular requirement specifies that encryption keys must be kept secure. Suppose your system is implemented using a public key cryptography approach such as pretty good privacy (PGP), in which there also is not a centralized certificate authority; there are no keys to keep secure! So, your compensating control is the use of a PKI system and the details by which you protect and manage certificates. (Yes, that process involves the use of both parties’ private keys, and yes, those have to be kept secure, but these are not the keys used to encrypt a PCI DSS transaction. And, yes, it’s arguable that the requirement would then apply to keeping the resultant session keys secure.)

Another example might be a requirement (in PCI DSS or many other systems requirements specifications) that requires passwords to be of a minimum length and complexity. Using a multifactor authentication system, common sense will tell us, obviates the need for attempts to constrain or dictate user choices of passwords since they are not the sole means of gaining access and privileges.

The Lifecycle of a Control

As with any systems element and the systems themselves, risk mitigation and security controls have a lifecycle that they progress through, from initial observation and expression of a need through implementation, use, and replacement or retirement. More specifically, that lifecycle might include the following:

• Risk identification and characterization
• Vulnerability assessments, with links to specific risks
• Risk management planning decisions, on a per-risk basis, in terms of what to accept, transfer, treat, or avoid
• Risk mitigation decisions, including specifics as to the chosen controls and the anticipated residual risk after the controls are put into practice
• Success criteria, in operational terms, which indicate whether the control is successfully performing its functions
• Anticipated ongoing costs and efforts to use and maintain a set of controls
• End-user and support team training, including any requalification training, needed to keep the controls operating effectively
• Continuous, ongoing monitoring of operational use of the controls
• Ongoing periodic or random assessment, including penetration testing, aimed at assessing the controls
• Decisions to upgrade, replace, or completely retire a set of controls

As you’ll see in Chapter 3, there are a number of information products generated by risk management and risk mitigation planning. Although they may be known by various names or be produced in many different formats, the core set of information includes the business impact analysis, risk assessment, risk mitigation plan, and the change management and baseline documentation for the chosen and implemented controls. These could include vendor-supplied manuals as well as your organization’s own functional performance requirements allocated to a particular control.

Asset Inventory

Information systems asset management starts with the asset inventory, which must completely and unambiguously identify every information systems element to be managed as an asset. The inventory should include hardware, firmware, software, virtual machine environments, cloud systems services, databases, websites, and the supporting documentation for end users and maintainers.

Having a current and complete inventory is the absolute bedrock for implementing and monitoring technical security controls.

Robust asset inventory tools and processes will also inform the organization of unauthorized assets. These may be unlicensed copies of software or uncontrolled devices, software, or systems used by employees, clients, or visitors that thus become parts of your system. They may also be elements of an intrusion in progress. Each of these situations could be risks to the overall safety, security, and reliability of your IT systems.

Note that almost any device that can attempt to access your networks or systems is an object to be inventoried, placed under configuration control, and incorporated into your access control systems’ databases as an authenticated identity. Failing to tie these three processes together—and keep them tied together—leaves an unnecessary degree of access open to potential intruders.

Lifecycle (Hardware, Software, and Data)

Although some legacy systems may seem to be lasting forever, it’s much more common that information systems assets of every kind have a useful economic life span, beyond which it is just not useful or cost-effective to continue to use it and keep it working. Once past that point, the asset should be disposed of safely, so as to terminate exposing the organization to any risks associated with keeping it or failing to care for it. The typical systems development lifecycle model (SDLC) can be applied to hardware, systems software, applications software, and data in all of its many forms; let’s look at this from an asset manager’s perspective:

• The requirements phase identifies the key functional and physical performance needs that the system should meet and should link these to the organization’s mission, goals, and objectives. When any of these change, the asset manager is one of the stakeholders who evaluates whether the asset is at or past its useful economic life.
• During the design phase, the functional requirements are allocated to individual elements of the design; it’s worth considering at this point whether these components of the total system should be tracked as assets by themselves versus tracking the system as a whole or as a single asset.
• Development, integration, and acceptance testing quite often conclude with a list of identified discrepancies that must be tracked and managed. In effect, each open discrepancy at the time of systems acceptance is a lien on the overall value of the system (much as a mortgage or mechanic’s lien on your home reduces the equity you would realize from selling your home). Tracking those discrepancies is a form of tracking residual risk.
• Operational use presents an opportunity to appraise the value of the system; finding new uses for it increases its value to the organization as an asset, but if users find better, faster ways to do the same jobs instead, this in effect decreases the value of the asset.
• Maintenance and upgrade actions can extend the useful life of the system while adding to its cost. This is also true for ongoing license payments, whether as per-seat or site-wide licenses for software use.
• Retirement and safe disposal, and the costs associated with these, bring this particular asset’s lifecycle and its asset management account to a closed state.

Disposal must deal with the issue of data remanence, which refers to information of any kind remaining in the memory, recording surfaces, physical configuration settings, software, firmware, or other forms. This applies to more than just the familiar disks, tapes, and thumb drives; all hardware devices have many different internal nooks and crannies through which live data flows during use. Old-fashioned cathode ray tube (CRT) displays risked having images burned into their display surfaces. Printers have been known to go to the scrap dealer with fragments of previously printed documents, or impressions on their printing drums and ribbons of what they last printed, still legible and visible. Printed documents may need to be shredded or pulped. As a complication, you may end up having to store these retired assets, at a secure location, while awaiting the time (and money) to have a proper zeroization, purge, or destruction of the element to prevent an unauthorized disclosure from happening.

Hardware Inventory

In many work environments, people and whole workgroups can move around within a large facility. People shift from one workstation to another or to larger (or smaller) spaces in another room or another building; some may even move to a different city or country or travel extensively. Hardware inventory needs to know logically and physically about each device, be it an endpoint, a server, a peripheral such as a printer or scanner or a removable storage device. Assuming for a moment that no MAC address spoofing or alteration is allowed, the identity of an individual device should remain constant; knowing that it’s currently attached via a certain IP address and that it is (or is not) connecting through a VPN is part of knowing logically where it is. But…knowing physically what desk or tabletop, rack, room, building, or continent it’s on (or in) can be problematic. It’s prudent to avoid procedurally intensive ways to address this problem, as the German military found out a few years ago. They went from simply allowing their military and civilian staff to just pick up and move their desktop and laptop computers from office to office, as temporary shifts in duties arose, and instituted a work-order process as a way of capturing location information for their asset inventory. This added days of work as each move had to have a form filled in, which was sent to an approvals and dispatch center; then had to have a worker move the equipment; and finally have the form sent back to the user to sign off that the move was now complete. Attribute-based access control (ABAC) may be a smarter solution to such problems, although it may require endpoints that can be trusted to accurately report their physical location without end-user intervention.

I cannot overstress the need to know the physical location for infrastructure elements such as servers, routers, switches, and such, to as detailed a level as possible. Precious time can be wasted during an incident response by having to search for which room, which rack, and which unit or position in the rack is the device that’s been sending up alarms (preferably not sending up smoke signals). It’s also especially important to note which power distribution panel or circuit breaker box serves each equipment rack or bay and which power conditioning systems feed which distribution panels or breaker boxes.

Software Inventory and Licensing

Software and firmware come in many different forms; almost without question, all of these forms should be under the right combination of configuration control, configuration management, and asset management. Between those three processes, you’ll have a very good chance to know that all of your software elements:

• Have been protected from unauthorized changes
• Have had all required changes, patches, and updates correctly applied
• Have had all outstanding discrepancy reports or change requests reviewed and dispositioned by the right set of stakeholders and managers
• Where each element is, physically and logically, how it’s being used, and whether or not it is up to date

You’ll also know, for each software element, whose intellectual property it is and whether there are license terms associated with that ownership interest. For each license, you’ll need to know the detailed terms and conditions that apply and whether they apply to all copies you’ve installed on any number of devices or to a specific maximum number of devices; the license may also restrict your ability to move an installed copy to another system. The license might be seat limited to a specific number of individual users or capacity limited to a maximum number of simultaneous users, maximum number of files or records, or other performance ceilings.

Many modern applications programs (and operating systems) facilitate this by using digital signatures in their installation processes so that each installed and licensed copy has a unique identifier that traces to the license identifier or key. Software license inventory management tools can easily poll systems on your network, find copies of the application in question, and interrogate that installation for its license and identifier information. This can also find unlicensed copies of software, which might be legitimate but have yet to activate and register their licenses or might be bootleg or unauthorized copies being used.

Proper software license management and software inventory management can often save money by eliminating duplicate or overlapping licenses, or by restricting usage of a particular app or platform strictly to where it’s needed.

Data Storage

Whether you think of it as data or information, it is either in use, in motion, or being stored somewhere in the information architectures and systems you are keeping safe and secure. Data can be used by endpoints, servers, or the infrastructure itself. Data is in motion when it is being transferred across networks, communications links, or even to and from a storage device temporarily attached to an endpoint computer or smartphone. Data can be stored – be at rest – in endpoint devices, in removable media, and in storage subsystems that are part of an on-premise network or hosted in a public or hybrid cloud. Chapter 7, “Systems and Application Security,” will look in greater depth at security issues relating to data storage in the cloud and within your networks and their servers. What remains is the vexing problem of data storage on paper and on removable storage media and devices, and when those storage media and paper documents are being moved around.

Information Lifecycle

Information has a natural lifecycle, but as with most things in the IT world, there are many different models for this lifecycle, with different emphasis placed on different phases of the data’s existence. For example, ISO 27002 defines this cycle with five phases: creation, processing, storage, transmission, and deletion/destruction (see Figure 2.2). Other models, such as those built into many systems management platforms such as SAP, may combine creation and use with processing; then add a retention phase in which the data is not actively used but cannot be disposed of because of legal, regulatory, or liability reasons; and finally end with a disposal and destruction activity.

Security is an important consideration at every phase, but the level of importance can vary, depending on the phase. The formats and media used in the various phases can also affect the security considerations.

Consider, for example, design documents for a new product or technology. When those documents/data are new, they are valuable and actionable, especially if a competitor acquires them. Once the product or technology is in production and is being sold on the market, those same documents could be near the end of their lifecycle. At this point, one could argue that the documents would do less damage in the hands of a competitor, but they still need to be afforded some level of protection, right up to the moment they are destroyed. In this example, even though the creators have benefited from the “rush to market” advantage, the design documents themselves could still contain sensitive data, such as a proprietary production method, which the organization plans to reuse in future products.

There are several important points to take from this example. First, the security impact may vary depending on where the information is in its lifecycle. Next, even though the impact may vary, there can be negative outcomes for the organization at any phase. Finally, phase five, the deletion and destruction phase, is important because destruction of unneeded assets reduces the organization’s attack surface. Data at the end of its lifecycle only introduces risk, with little to no benefit.

The lifecycle view shows that datasets (or information assets) are constantly going back and forth from storage to use; throughout that ever-repeating cycle, your systems designs should protect the information while it is at rest, in use, and in motion. Currently, well-chosen encryption systems can protect data in motion and at rest and by means of digital signatures offer the stored copies protection in time as well. (Chapter 5 goes into this in further detail.) However, thus far there are not many solutions to protect data while it is being used from compromise or loss, since most operations on data and its use by humans needs to have the meaning of the data readily available.

Technical Controls

In all cases, you should first have an administrative (people-facing) control document, such as a policy statement or a procedure, that provides the justification and the details you need to configure, operate, inspect, and update all of the technical settings that implement the electronic aspects of your security architecture. These include both the networks, servers, and endpoint technologies, such as software Group Policy Objects, parameter files, access control lists, or even jumper and patch panel settings. Also included are the programming, options, and controls for fire and safety alarm systems, motion detectors, entryway alarms, power conditioning, and environmental control systems. (Remember, it was through a maintenance back door in the heating, ventilation, and air conditioning systems that attackers were able to gain entry into Target’s systems in 2013.)

Two of the most common technical controls used in many security strategies are related to setting time limits on user activity. Session timeouts or inactivity lockouts can be implemented on an endpoint device level, on a per-user ID level, or by individual applications platforms, servers, or systems. They force a user to take a positive action to reconnect or renew a login (and go through some or all authentication factor steps) to continue, once their device, session, or use of that resource has been inactive for a specified period of time. This can be frustrating to users when they’ve come into a system via SSO authentication, gaining initial access to a set of resources and applications at the start of their workday but then having to repeatedly log back in again when they’ve let individual sessions with specific apps or servers go idle for too long. Session timeouts provide protection against the “lunchtime attack,” which got its name from an intruder being able to wander around an office building and find computers unattended but still logged into the system during lunch breaks. Device-level timeouts on company-managed endpoints are typically set for short periods, such as 10 minutes, based on similar reasoning. Specific applications platforms and the portals that your users access them through may need to impose their own timeout periods and choose whether to use timeout warning reminders, based on specific systems security needs.

Another time-based technical control, the merits of which are hotly debated, is password aging; this sets a time period (usually measured in days, not minutes) after which a user must change their password. Other password policy settings can limit password reuse as well. Password aging, length, complexity, or other password characteristics should be determined as part of your integrated approach to identity management and access control; proper implementation of multifactor authentication, for example, may provide greater security and ease of use than complex, rapidly aging passwords were once thought to provide.

All of these settings should be subject to formal configuration management and control and documented in some fashion so that an incident response team, network operations staff, or the IT team can quickly refer to them to determine whether the alarms are sounding due to a misconfigured control or because a security incident is occurring.

Physical Controls

Physical controls are things you can touch (or bump into); they are the walls, doors, locks, fences, mantraps, concrete barriers, and their relative placement in your overall physical arrangement of a facility. By themselves, physical security features provide deterrent, prevention, and containment capabilities; to get your money’s worth out of them, most organizations add monitoring equipment such as cameras, motion detectors, alarms, and people (and perhaps security canine patrols). Gluing that all together requires administrative controls in the form of policies, procedures, and control documentation. It also relies upon the human element—the monitors, the watch-standers, and the administrative and technical people who make it work and who use it to secure and protect the organization, its people, its information, and its assets.

Physical security architectures usually place high-value assets and systems within multiple, concentric rings of physical perimeters. Entry onto the property might require going past a guard post; checkpoints at the entries to individual buildings on the property would authenticate the individuals attempting to enter and possibly conduct a search of the personal property such as briefcases or backpacks under their control. (Most jurisdictions do consider that owners or managers of private property have the legal right to require that visitors or staff voluntarily allow a search of their person and belongings and deny entry to those who decline to cooperate with such a search.) Once inside, access to high-value areas such as documentation or software libraries, financial operations centers, server and network rooms, or security operations control centers are further restricted, perhaps requiring two-person control as part of authentication procedures. Layer by layer, these cascades of entry and control points buy time for the defenders, time in which any errors in authentication can be detected or subsequent attempts by the subject to exceed authorized privileges generate alarm conditions.

Controlled entry systems, such as mantraps and turnstiles, are electromechanical systems at heart. On the one hand, these must interface with some portion of your identity management and access control systems to be effective; on the other hand, they need routine maintenance, as well as remedial maintenance when they fail during use. In most cases, human guards or controllers are present in the immediate vicinity of such control points.

Controlled egress systems may employ the same physical, logical, and administrative tools as used to control entry into and movement within a facility; they bring the added benefit of controlling inventory, equipment, software, or data loss (sometimes called shrinkage by wholesale and retail businesses), by both deterring and preventing unauthorized removals from occurring. This usually requires a degree of search of property as it leaves the controlled area. A growing number of high-technology firms, especially in biotechnology, rigorously enforce controlled egress and search as vital components of protecting their intellectual property and competitive advantage.

Video and audio monitoring systems have become standard elements in most security systems—and all the more so as the costs of fully digital systems have become much more affordable. Even the small office/home office (SOHO) entrepreneur can afford a multicamera, digital video recorder security system, complete with Internet interfaces for remote monitoring. Many security cameras now come with infrared LEDs that provide surreptitious illumination of the scene, which improves monitoring significantly without needing to add visible light floodlighting systems and their power distribution and control elements.

Inspection and maintenance of physical control systems is vital to continued security. Administratively, there should be no surprises here; if a maintainer or inspector shows up, your on-shift, on-site guards and monitors and the security control force all need to first authenticate their identity and further confirm that they’ve been properly called out or dispatched to perform a specified set of tasks.

All physical control systems elements should be documented and under formal configuration management and control appropriate to their physical nature. Concrete block exterior walls, for example, should not be subject to having holes drilled or cut into them without proper authorization. The security department might not control or manage all of this documentation or the change management processes for the structural elements of the physical security aspects of your systems; regardless, your organization’s security needs suggest how closely the building maintenance teams and the security teams need to work with each other.

Administrative Controls

In most organizations and the cultures they are rooted in, there is a natural hierarchy of guidance and direction, starting with broad, sweeping, and visionary statements that get progressively less motivational as they become more prescriptive. Subsequent layers become proscriptive, tending to have as many “thou shalt nots” as they have “shall” statements in them (if not more). Although the names for many of these layers may be different in different settings and cultures, it’s still reasonably useful to expect the same basic layers of policies, standards, procedures, baselines, and guidelines.

Periodic Audit and Review

There are two major shortcomings with most human-facing procedural and administrative controls for security and risk mitigation. The first is that in their human-facing form as an end product, they invariably end up being anywhere but right at the point of contact between the humans involved and the vulnerable system element the administrative controls are designed to protect. Policies and procedures distributed on paper or as email attachments end up being lost or buried in a desk drawer or folder tree and forgotten about. Signs and warning placards catch the eye during the first few days or weeks after they’ve been posted, but after a while, the human mind tunes them out; they’re just part of the visual clutter of the background.

Because of these shortcomings, it’s good to audit your administrative controls with an eye to separating them into two major categories: those that direct or require a real-time action, such as emergency notification and incident response; and those that provide longer-term guidance for behavior, such as inappropriate or unauthorized use of company-provided assets and resources. That first category represents opportunities for some smart investment to ensure that just the right amount of policy guidance, direction, and constraint is at the right fingertips at the right time.

Execute Change Management Process

As the systems security analyst and administrator, your duties may combine or overlap with those of other systems administrators who actually install, manage, and maintain the operating systems, applications, platforms, web pages, and datasets that make up your organization’s IT architecture. Without their extensive training and significant experience with those products, it’s probably unrealistic for you to try to manage both the security configuration and the product configuration for each installed product. Let’s look at a few of the methods and tools used in establishing and managing both kinds of configurations.

Manual configuration is the easiest to understand conceptually—it involves the administrator viewing and changing the configuration settings directly, either by editing a configuration settings data file or by using something like the Windows Registry Editor (regedit). Registry edits (or their equivalents in other operating systems environments) can also be done using batch or script files. Either way, this is a fine-grained, detailed, step-by-step process, which can be useful if you’re stepping through various settings to diagnose a problem or as part of an incremental hardening process.

Configuration scanning tools can read the stored data structures used by the operating system and installed programs, extract information from those settings, and in some cases test some of those configuration settings for validity. The resulting list of all of these settings is sometimes called a configuration enumeration. NIST maintains a set of Common Configuration Enumerations that have been associated with security issues that are tracked in the National Vulnerability Database (NVD), and more recent versions of configuration scanning tools can help you detect similarities between a CCE and your system’s current configuration. The CCE database can then provide you with insights and recommendations, drawn from best practices in the field, as to changes you should make in your systems to improve their overall security.

In the same breath, NIST and others often provide, specify, or recommend systems hardening information as it pertains to a given configuration enumeration. As a result, some professionals refer to the total bundle (the enumerated configuration and its related hardening information) as an enumeration or as a set of hardening standards for a particular configuration. Since the purpose of having the enumerated configurations in the first place is to collate hardening recommendations with specific configuration items and settings, this is to be expected. If in doubt as to what is meant or included, ask for clarification.

Another useful tool is a configuration change detection tool. It is different than a configuration scanner tool in that instead of asking the IT asset “Are you configured correctly?” it asks, “Did your configuration change?” It takes a snapshot of a given system’s configurations, presumably after it was configured correctly and securely. Then, if any of the configurations are changed, it sends an alert to one or more relevant security stakeholders. Vendors are adding additional features and capabilities to both scanner tools and change detection tools, blurring the line between the two. Some tools now do both.

When you want to control how your security tools share data, you can use the Security Content Automation Protocol (SCAP). SCAP is a way for security tools to share data. It is an XML-based protocol that has many subcomponents called specifications, including one for CCE. It is a taxonomy for describing configuration requirements, which is essential because of the sheer number of configurations and their nuanced differences.

CCEs are written for, and are grouped by, specific IT products or technology types. The vulnerability equivalent to CCE is the Common Vulnerabilities and Exposures (CVE). CVE is more widely adopted than CCE because the vulnerability scanner market is larger and more mature than the configuration scanner market. In fact, some major vulnerability scanning tool vendors have added CCE (configuration) scanning to their traditional CVE (vulnerability) capabilities. Learn more about CCEs at https://nvd.nist.gov/config/cce/index.

In addition to other standards and guides, vendors (especially OS vendors) typically publish secure build outlines for their own products and often make tools available for provisioning and monitoring configurations.

Identify Security Impact

Any proposed change, even applying a patch kit or bug fix to alleviate a security problem, may inadvertently introduce a new vulnerability or a new risk into your systems and your business operations. Change packages should be examined to identify any potential changes to your operational procedures for getting work done with the affected systems and assets. Descriptions of the changes, and in particular the issues or vulnerabilities that are acknowledged as not addressed in the patch or update kit, should also be closely looked at to see if they suggest possible new areas of risks to your operations. If it’s practical for you to delay installing the update until other organizations have installed it and operated on it for a short while, you may want to consider this—but only if you have an alternative way to protect your system from exploits targeted at the vulnerabilities the patch or update is going to remediate!

When analysis fails to surface anything to help alleviate your fears of causing more trouble and risk with an update than the fix is trying to eliminate, it may be time for some security-driven testing.

Testing/Implementing Patches, Fixes, and Updates

Chapter 7 goes into more detail on the overall software development process and the concepts behind the software development lifecycle (SDLC) models, both classic and cutting-edge, that are in widespread use today. As the security administrator or team member, you may need to be involved in the overall development process to ensure that any security-relevant issues, perspectives, functional requirements, and insights get incorporated into both the product as it is developed and the management process that keeps that development on track. At some of those test opportunities—which there are more of in a large systems development than there would be for a small, tightly focused patch or update—security may need to be more of an active member of the test team and not just an interested stakeholder and observer. Your experience and insight about what happens when systems fail to be secure can be of great help to test teams as they conduct scenario- based test cases; your knowledge of how the application or system under test should be interacting with network and systems security monitoring and incident detection tools may also benefit the post-test analysis activities as well.

It is best and common practice to do security-related testing in an isolated testing environment, safely quarantined off from your live production environments. Virtual machines in tightly secured test and development subnets, and hosts are ideal for this. This contains any problems that the test may otherwise set loose into your production systems or out into the wild. It also allows you to be more aggressive in stressing the system under test than you could otherwise afford to be if testing were conducted on or associated with your live production environment.

You can also adapt penetration testing scenarios and approaches you would otherwise use against your systems hosted in an isolated testing environment, before you’ve released those new versions of the systems into live production and operational use. Black box, white box, or other forms of penetration testing may be quite useful, depending upon the nature of the changes you’re trying to evaluate.

Security Awareness Overview

It’s easy to see that in almost every organization, no matter how large or small its workforce, no one single person can possess the knowledge, skills, abilities, and attitudes to successfully do all of the jobs that make that organization successful. By the same token, no one information security professional can keep all of the systems and elements of the IT architecture secure and plan, develop, and teach the security awareness, education, and training programs the rest of the workforce needs. What any of us can do—what you can do—is to take a thumbnail sketch of what such programs need to achieve, share this with management and leadership, and assist where you can with the expertise and talent you do have to make that sketch of a plan become reality. Let me offer you some thoughts about this, from my experiences as an educator, trainer, and information security professional.

Let’s start with awareness—the informed recognition that a set of topics, ideas, and issues exists and is important. Awareness shines a different light on the day-to-day, triggering moments of recognition. Awareness shatters the false myths, the explanations that everybody “knows” but have never tested for validity. Simple but compelling examples can do this; even something as simple as “fake phishing” attack emails that you send to your own workforce can, over time, increase the percentage of that workforce that get better at spotting a possible attack and dealing with it immediately and correctly.

Education explains concepts and links them to awareness. Education can be formal, focused around an identified body of content or aimed at the student attaining a credential of some kind attesting to their accomplishment. Informal education can be just as effective and often is well suited to rapidly evolving situations. Education stimulates thinking and creativity. A short course in root cause analysis can start with getting students to recognize the power of simple, open-ended questions.

Training teaches skills and guides learners in becoming increasingly proficient in applying them to realistic situations. Training activities that use “spotters’ guides,” for example, can demonstrate packet sniffing and filtering or anti-phishing email screening techniques and then use checklist approaches as the frameworks of labs and exercises to enhance learners’ abilities to recognize concepts in action and make informed decisions regarding actions to take.

Competency as the Criterion

It’s well worth the investment of time and thought to create a short list of the key information security competencies that different subgroups of your workforce need, if they are going to be able to make real contributions to improving information security for the team as a whole. The larger your organization and the more diverse the individual workgroups are in terms of tasks, context, and the sensitivities of the information they work with, the greater the likelihood that you’ll need numerous short lists of such competencies. This is okay; make this manageable by starting with the groups that seem to need even a small step-change in security effectiveness and work with them to identify these core competencies.

By the way, some education and training program professionals will refer to this core competencies approach as a needs assessment. The name does not matter; the results do. Both should produce as an outcome a list of tangible, clear statements of what learners need to learn and the standards by which they must be assessed to demonstrate the success of that learning.

It’s likely that your company or organization has trainers and human resources developer talent within the HR or personnel department. Find them; get them involved. Get their help in translating these first few sets of core competencies into the next layer of detail: the activities that learners have to perform well at to demonstrate that they’ve successfully learned that competency to the required degree of rigor. Get them to help you find teaching and learning assets and materials that the company already has; or, get them to help you find other assets. Reuse what you can find, learning from how well it works, before spending the time to develop something custom-made for your situations, people, mission, and needs.

Build a Security Culture, One Awareness Step at a Time

You’ve successfully engaged others in the company to take on the tasks of selecting or developing the teaching and learning assets, structuring the courses, and finding the right people to act as trainers and teachers. You’ve got them managing the identification of which employees need what levels of learning, how often they need it, and when they need to get the learning accomplished. As the on-shift or day staff security administrator, that’s a great segregation of duties to achieve! Now what?

Walk the hallways of the company’s campus or locations; keep your eyes and ears open for signs that awareness, learning, and skills-building are happening. Look for signs of trouble that suggest it isn’t working fast enough or well enough. Step into those situations informally and casually, and lead by example and inspire by action and word. Suggest to people in these problematic contexts, be they workers, supervisors, or mid-level managers, that they’ve got the opportunity to empower themselves, and you can help them.

Too many organizations fall into the administratively simple task of regularly scheduling repetitive training activities. These could be messaging opportunities that strengthen each worker’s future with the company by enhancing the organization’s survival and success. Instead, they oftentimes turn them into tick-the-box, square-filling exercises in futility. If this is happening in your organization, shine some light on it; help others become aware of the need to turn that messaging around. Quickly.

Physical Access Control

If the attackers can get to your systems, they’ve got a chance to be able to get into them. This starts in the physical domain, where access includes physical contact at Layer 1 network systems, at the USB ports or memory card slots on your endpoints and other devices. It includes being able to see the blinking LEDs on routers (which blink with each 1 or 0 being sent down the wire), and it includes being bold as brass and just walking into your office spaces as if they’re a pizza delivery person or business visitor. And although we’ve not yet seen it reported, it won’t be long now before we do see an attacker using hobbyist-grade UAVs to carry out intrusion attempts.

Chapter 1 looked at the concept of defense in depth, integrating a variety of deterrence, prevention, and detection capabilities to defend the points of entry into your systems. Threat modeling, done during the risk assessment and vulnerability assessment phases (which Chapter 3 examines in more detail), have given you maps of your systems architecture, which show it at the data, control, and management planes as well as in the physical dimension. Start at the outermost perimeter in those four planes and put on your penetration-tester hat to see these control concepts in action.

One major caution: What you are about to do is tantamount to penetration testing, and to keep that testing ethical, you need to first make sure that you’re on the right side of law and ethics. Before you take any action that might be construed as an attempted penetration of an organization’s information systems or properties under their control, gain their owners and senior managers permission in writing. Lay out a detailed plan of what you are going to attempt to do, why you propose it as worthwhile, and what you anticipate the disruptions to normal business operations might be. Work with them to specify how you’ll monitor and control the penetration test activities and how you’ll suspend or terminate them immediately if required. As you learn with each step, err on the side of caution and go back to that management team and ask for their written permission to take the next step.

At a minimum, this will keep you out of jail. It will enhance your chances of staying employed. It will also go a long way toward increasing the awareness of the threat and the opportunity that your management and leadership stakeholders have to do something about it.

The Data Center

As the focal point of the data assets of the organization, the data center is in particular need of protection within the property/facility. The data center also has some specific requirements that make it somewhat different than the rest of the production environment. In addition to the other access controls placed on secure areas within the workplace (discussed earlier in this chapter and in Chapter 5), security of the data center should include consideration of the following factors:

• Ambient temperature: IT components generally function better in relatively cold conditions; if the area is too hot, the machines will not function optimally. However, if the area is too cold, it will cause discomfort for personnel.
• Humidity: An interior atmosphere that is too dry will increase the potential for electrostatic discharge. An atmosphere that is too damp will increase the potential for development of mold, mildew, and insects.

Standards for maintaining a desirable range of data center environmental conditions should be used to establish targets. One such reference is the ASHRAE Technical Committee 9.9 thermal guidelines for data centers; see http://ecoinfo.cnrs.fr/IMG/pdf/ashrae_2011_thermal_guidelines_data_center.pdf.

The data center should also be designed, constructed, and equipped for resiliency, such that it is resistant to unplanned outages from human error/attack, system/component failure, or natural effects. This is typically accomplished by including a great deal of redundancy within the data center. The use of design standards to achieve a significant level of robustness and resiliency is highly recommended.

The Uptime Institute publishes a multitier standard for use by data center owners in determining and demonstrating their particular requirements and capabilities (“Data Center Site Infrastructure Tier Standard: Topology”; see https://uptimeinstitute.com/tiers). The tiers range in purpose and requirements from basic data centers that might be used for archiving or occasional data storage to facilities that support life-critical processes. The CISSP should have a cursory knowledge of the four-tier levels and their descriptions. (For more information, see https://journal.uptimeinstitute.com/explaining-uptime-institutes-tier-classification-system/.)

The standard is free for review/guidance; certification against the standard is performed only by the Uptime Institute and requires payment.

Organizations that receive Uptime Institute tier certification for their data centers can be listed in the Institute’s online register: https://uptimeinstitute.com/TierCertification/allCertifications.php?page=1&ipp=All.

Finally, fire poses a significant, common risk to data centers because of the high potential for occurrence and because of the disproportionately heavy impact a data center fire would have on the organization. The selection, design, implementation, maintenance, and use of fire protection and alarm systems can be quite complex, and in many jurisdictions must be undertaken by a properly licensed fire protection engineer. Municipal standards such as building codes also must be taken into account. Insurance providers may also levy strict inspection and compliance constraints on any and all fire protection systems and practices in order to maintain policy coverage. This all goes well beyond what the SSCP can or should attempt to take on.

Service Level Agreements

In the modern IT environment, there are many reasons (not the least of which is cost) for an organization to consider contracting with an external service provider to handle regular operational tasks and functions. To create a contract favorable for both parties in this sort of managed services arrangement, everyone involved must clearly understand what is being requested, what is being provided, what the cost is, and who is responsible for what. This is particularly important in what could be considered the most popular current form of managed services: cloud-managed services. In the majority of cloud-managed service contracts, the cloud provider and customer must determine the expected level of service, and the contract or service level agreement is the element that gives both parties the confidence to expect defined outcomes: assuring the provider that they will receive payment and assuring the customer that the service will meet the customer’s needs.

In these cases, you need a formal agreement that defines the roles and responsibility of each party, explicit to the point where it can be easily understood and measured. The common name for this is the service level agreement. However, depending on the services provided, the agreement can go by other names, like network services agreement, interconnection security agreement, etc. The SLA is part of the overall contract but deals directly with the quantifiable, discrete elements of service delivery.

These are scenarios where an organization might need an SLA:

• Third-party security services
  • Monitoring/scanning
  • Security operations center/response-type services
  • Media courier/media disposal
  • Physical security
• Hosted/cloud
  • Servers
  • Storage
  • Services
• Interconnecting information systems, especially with data feed/pull/push
• Supply chain scenarios

The SLA portion of the contract vehicle is best limited to those elements of the managed service that are routinely provided as part of continual operational requirements; the SLA is not the optimum place for including contingency requirements (such as BCDR tasks) or for anything that cannot be distilled into a numeric value.

Mechanism for Monitoring Service

It is not enough, however, just to understand the terms of the SLA. You also need a mechanism with which to monitor and measure whether the service provided matches the level specified in the SLA.

To continue with the previous example of AWS, visit https://status.aws.amazon.com/. You will initially see a dashboard similar to Figure 2.3. The horizontal rows represent the AWS regions. If you look at the corresponding region where your servers are hosted, you can see whether they are having, or have had, any degradation of service or outages.

While this dashboard can be used to inform the customer as to the efficacy of the service overall, it might not provide, by itself, the level of assurance the customer desires; the information is necessarily coming from the provider, and the provider has a vested interest in the outcomes of the data (i.e., getting paid) and so is inherently biased. For such SLA elements, the customer may prefer some third-party validation of the service/data to feel confident that the reporting mechanism adequately reflects the actual level of service provided/received.