Chapter 1: Introduction Spring 2020 Dr. Sherri Brinson Welcome • Chapter 1: Introduction • 1.1 Breach! Fix It! • 1.2 Information Security, as Applied to Systems • 1.3 Applying Security to Any System Chapter 1: Introduction • 1.1 Breach! Fix It! • Advances in information security have been repeatedly driven by spectacular attacks and by the evolutionary advances of the attackers. • The password file for millions of customers was stolen through the front end of a web site pulling in 90% of a multi-billion dollar revenue stream. • The chance of an attempted attack of one kind or another is certain. The probability of a web attack is 100%; systems are being attacked and will be attacked regularly and continually. • Indeed, system complexity leads to increasing the difficulty of defense and, inversely, decreasing the difficulty of successful exploitation. The number of flows between systems can turn into what architects call, “spaghetti,” a seeming lack of order and regularity in the design. Chapter 1: Introduction – Cont. • If a breach or significant compromise and loss creates an opportunity, then that opportunity quite often is to build a security architecture practice. A major part or focus of that maturing security architecture practice will be the assessment of systems for the purpose of assuring that when deployed, the assessed systems contain appropriate security qualities and controls. • Sensitive data will be protected in storage, transmission, and processing. • Sensitive access will be controlled (need-to-know, authentication, and authorization). • Defenses will be appropriately redundant and layered to account for failure. • There will be no single point of failure in the controls. • Systems are maintained in such a way that they remain available for use. • Activity will be monitored for attack patterns and failures. Chapter 1: Introduction – Cont. • 1.2 Information Security, as Applied to Systems • Security architecture applies the principles of security to system architectures. • Without security architecture, the intrusion system (IDS) might be distinct and independent from the firewalls (perimeter). Firewalls and IDS would then be unconnected and independent from anti-virus and anti-malware on the endpoint systems and entirely independent of server protections. • The security architect first uncovers the intentions and security needs of the organization: open and trusting or tightly controlled, the data sensitivities, and so forth. Chapter 1: Introduction – Cont. • When standards do not match what can actually be achieved, the standards become empty ideals. In such a case, engineers’ confidence will be shaken; system project teams are quite likely to ignore standards, or make up their own. Security personnel will lose considerable influence. Therefore, as we shall see, it’s important that standards match capabilities closely, even when the capabilities are limited. In this way, all participants in the system security process will have more confidence in analysis and requirements. Chapter 1: Introduction – Cont. • Decision makers need to understand precisely what protections can be put into place and have a good understanding of any residual, unprotected risks that remain. • A suite of controls implemented for a system becomes that system’s defense. If well designed, these become a “defense-in-depth,” a set of overlapping and somewhat redundant controls. Because, of course, things fail. One security “principle” is that no single control can be counted upon to be inviolable. Everything may fail. Single points of failure are potentially vulnerable. Chapter 1: Introduction – Cont. • The Open Web Application Security Project (OWASP) provides a distillation of several of the most well known sets of computer security principles: • Apply defense-in-depth (complete mediation). • Use a positive security model (fail-safe defaults, minimize attack surface). • Fail securely. • Run with least privilege. • Avoid security by obscurity (open design). • Keep security simple (verifiable, economy of mechanism). • Detect intrusions (compromise recording). • Don’t trust infrastructure. • Establish secure defaults. Chapter 1: Introduction – Cont. • 1.3 Applying Security to Any System • A typical progression of security maturity is to start by building one-off security features into systems during system implementation. During the early periods, there may be only one critical system that has any security requirements! It will be easier and cheaper to simply build the required security services as a part of the system as it’s being implemented. As time goes on, perhaps as business expands into new territories or different products, there will be a need for common architectures, if for no other reason than maintainability and shared cost. It is typically at this point that a security infrastructure comes into being that supports at least some of the common security needs for many systems to consume. It is characteristically a virtue to keep complexity to a minimum and to reap scales of economy. Chapter 1: Introduction – Cont. • Almost every type and size of a system will have some security needs. Although it may be argued that a throw-away utility, written to solve a singular problem, might not have any security needs, if that utility finds a useful place beyond its original problem scope, the utility is likely to develop security needs at some point. • Complex business systems typically have security requirements up front. In addition, either the implementing organization or the users of the system or both will have security expectations of the system. But complexity is not the determiner of security. • Thus, the answer as to whether a system requires an ARA and threat model is tied to the answers to a number of key questions: • What is the expected deployment model? • What will be the distribution? • What language and execution environment will run the Chapter 1: Introduction – Cont. • Size, business criticality, expenses, and complexity, among others, are dimensions that may have a bearing, but are not solely deterministic. I have seen many Enterprise IT efforts fail, simply because there was an attempt to reduce this early decision to a two-dimensional space, yes/no questions. These simplifications invariably attempted to achieve efficiencies at scale. Unfortunately, in practice today, the decision to analyze the architecture of a system for security is a complex, multivariate problem. • The answer to “Systems? Which systems?” cannot be overly simplified. Depending upon use cases and intentions, analyzing almost any system may produce significant security return on time invested. And, concomitantly, in a world of limited resources, some systems and, certainly, certain types of system changes may be passed without review. The organization may be willing to accept a certain amount of unknown risk asa result of not conducting a review. Chapter 1: Summary Information assurance is achieved when information and information systems are protected against attacks through the application of security services such as availability, integrity, authentication, confidentiality, and nonrepudiation. The application of these services should be based on the protect, detect, and react paradigm.
• This means that in addition to incorporating protection mechanisms,
organizations need to expect attacks and include attack detection tools and procedures that allow them to react to and recover from these unexpected attacks.