Название: The Official (ISC)2 SSCP CBK Reference
Автор: Mike Wills
Издательство: John Wiley & Sons Limited
Жанр: Зарубежная компьютерная литература
isbn: 9781119874874
isbn:
Safety
SUNBURST and other attacks in 2020 and 2021 highlighted how little attention many organizations were paying to the physical control and interaction side of their information systems. Enterprises that did not directly use IT to control manufacturing systems, or command and control vehicles and heavy machinery, believed themselves safe from physical harm, and yet would blithely invest in smart buildings and IoT devices for use in their office environments. They believed that these operational technologies—OT systems that directly cause physical motion or action, or monitor and supervise systems that do—were sufficiently separated from their IT systems, such as their corporate data centers, that there was little danger of a vulnerability on one side of that IT-OT interface from causing harm to systems, data, and people on the other side. That has been shown to be a false hope.
Operational technologies (OT) include industrial control systems (ICS) and the supervisory, control, and data acquisition (SCADA) systems that direct their activities. OT also includes Internet of Things (IoT) devices, autonomous, mobile machines (from custodial devices to chaotic warehouse forklifts), and robots. Most smart city systems, particularly their mass transit, water and sewer, traffic control, and communications management systems are part of the OT world, as are smart building environmental, power, and security management systems at work and in the home. This list of OT use cases grows every day, and in each case, there are data sharing and collaborative control and supervisory linkages with IT systems at many levels. And in most cases, device control involves switching and detecting AC and DC power and signals as part of controlling physical actuators and sensors.
As older OT systems are being phased out, newer systems tend to be making greater use of the Common Industrial Protocol (CIP). This is a feature-rich set of functions that are used within OT architectures to provide management, real-time control, data acquisition, and safety intervention across an architecture. CIP can operate over IP networks, which allows OT regional control workstations to easily interact with organizational IT systems. OT and IT systems both share common problems, such as the challenges of establishing and maintaining a secure supply chain for software, firmware, and hardware updates. Access control problems are quite common; the information security hygiene measures you need to apply to almost every IT systems environment must also be applied to your organization's OT systems, although with different techniques and tools. Integrated visibility—having a SIEM-like insight into the combined IT / OT architecture of your organization—can be achieved, but it's not as straightforward as some vendors may make it seem.
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.
Fundamental Security 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.
Need to Know
Security classification and categorization should be the linch pin that ties together the organization's information security and risk mitigation efforts. It's what separates the highest-leverage proprietary information from the routine, nearly-public-knowledge facts and figures. Information classification schemes drive three major characteristics of your information security operations and administration.
Internal boundaries for information control: Many business processes have “insider knowledge” needed to inform decisions or exert control over risky, hazardous, or sensitive sequences of actions. These can and should be encapsulated with a layer that hides that inside knowledge by allowing controlled “write-up” of inputs and “write-down” of outputs to the points where they interface with other business processes. These boundaries surround data at higher levels, and the trusted processes that can manipulate or see it, from outer, surrounding layers of processes that perforce operate at lower levels of trust. (It's not a coincidence that that sounds like a threat surface.)
Standards for trust and confidence: It's only logical to require higher levels of trustworthiness for the people, processes, and systems that deal with our most vital information than we would need for those that handle low-risk information. In most cases, greater costs are incurred to validate hardware, software, vendors, our supply chain, and our people to higher levels of trust and confidence; as with all risk mitigation decisions, cost-effectiveness should be a decision factor. The information classification standards and guide should directly lead to answering the question of how much trustworthiness is enough.
Measures of merit for information security processes: The level of information classification should dictate how we measure or assess the effectiveness of the security measures put in place to protect it.
Taken together these form a powerful set of functional requirements for the design not just of our information security processes but of our business processes as well! But first, we need to translate these into two control or cybernetic principles.
Least Privilege
Least privilege as a design and operational principle requires that any given system element (people or software-based) has the minimum level of authority and decision-making capability that the specifically assigned task requires, and no more. This means that designers must strictly limit the access to and control over information, by any subject involved in a process or task, to that minimum set of information that is required for that task and no more. Simply put, least privilege implements and enforces need to know.
A few examples illustrate this principle in action.
A financial disbursements clerk, when generating payments against invoices from suppliers, has to access and use information about each supplier account as well as access his company's bank-related systems to make the payment take place. However, this clerk would not be expected to modify the information about where the payment should be sent, edit the invoice, or alter the amount of the payment. Nor would this clerk be expected to need any information about other employees, such as their payroll information, while generating payments to suppliers.
A process control system that actively manages a chemical processing system for a paint manufacturer would not normally be expected to access the Internet or have a need to run web searches of any kind.
Each time you encounter a situation in which a person or systems element is doing something in unexpected ways—or where you would not expect that person or element to be present at all—is a red flag. It suggests that a different role, with the right set of privileges, may be a necessary part of a more secure solution.
Least privilege should drive СКАЧАТЬ