CHAPTER 16 Building Secure Architectures
Design in art, is a recognition of the relation between various things, various elements in the creative flux. You can’t invent a design. You recognize it, in the fourth dimension. That is, with your blood and your bones, as well as with your eyes.
D H Lawrence
We present now some examples of how the patterns we have described in this book can be used to build secure architectures. We use the methodology we presented in Chapter 3, although other methodologies are also possible. It is even possible not to use any methodology, but in this case the application of the patterns depends entirely on the experience and knowledge of the designer. We first expand some aspects of our methodology, then show four examples taken from different types of applications, from financial [Bra08a], control [Fer10d], legal [Fer07c] and medical domains[Fer05g] [Fer12b] [Sor04] [Sor05].
The examples show the use of the patterns in the following stages of the application lifecycle:
Requirements stage. Use cases define the required interactions with the system. We study each action within a use case and see which attacks are possible. We then determine which policies would stop these attacks. From the use cases we can also determine the required rights for each actor, and thus apply a need-to-know policy. Analysis stage. Analysis patterns, and in particular semantic analysis patterns, are used to build conceptual application models. Security patterns are superimposed to apply security mechanisms. We build a conceptual model in which repeated applications of a security pattern realizes the rights determined from use cases. Design stage. We map the abstract security patterns identified in the analysis stage to design artifacts: interfaces, components, distribution and networking. Design mechanisms are selected to stop these attacks. User interfaces should correspond to use cases and may be used to enforce the authorizations defined in the analysis stage. Components can be secured by using authorization rules. Implementation stage. This stage requires reflecting the security rules defined at the design stage in the code. Because these rules are expressed as classes, associations and constraints, they can be implemented as classes in object-oriented languages. At this stage we can also select specific security packages or COTS components. We do not show examples of the deployment and maintenance stages.
16.1 Enumerating Threats An important aspect of security requirements is a systematic and accurate listing of the potential attacks (threats) to the system. With this listing we can decide what specific defense mechanisms to use. There have been several attempts to consider attacks to define the system security requirements, for example [Hal08b]. In our approach we consider each action in each use case and see how it can be subverted by an internal or external attacker [Bra08a] [Fer06c]. For those actions which use (read/write) or produce data, we can see how this data can be misused by the attacker, which results in a very complete (and possibly exhaustive) list of threats. From this list we can deduce what policies are necessary to prevent or mitigate the attacks. The idea is that all the use cases of an application define all the possible interactions of actors with the application. It is in these interactions where attackers could try to misuse the system.
Other approaches to enumerating threats based on attack trees are shown in [Sch99b] and [Ste02].
Use cases are not atomic, but imply a set of actions [Lar05]. For example, in a use case of borrowing a book from the library, one must check whether the user has a valid account, they are not overdue and so on. Consider a financial company that provides investment services to its customers. Customers hold accounts and send orders to the company for buying or selling commodities (stocks, bonds, real estate, art). Each customer account is in the charge of a custodian (a broker), who carries out the orders of the customer. Customers send orders to their brokers by e-mail or by phone. Brokers advise their customers about investments. A government auditor visits periodically to check for application of laws and regulations.
Figure 16.1 shows the use case diagram for this institution. Figure 16.2 shows the activity diagram for the use case ‘Open an account’. Potentially each action (activity) is susceptible to attack, although not necessarily through the computer system. For each potential attack (threat) we can attach a possible goal. For this use case we could have the following potential threats:
Figure 16.1: Use cases for a financial institution
Figure 16.2: Activity diagram for the use case ‘Open an account’
Threat 1 The customer is an imposter and opens a spurious account to transfer money at a later time. Threat 2 The customer provides false information and opens an account with this false information. Threat 3 The manager is an imposter and collects user information. Threat 4 The (legitimate) manager collects customer information to sell or use illegally. Threat 5 The manager creates a spurious account with the customer’s information. Threat 6 The manager creates a spurious bank card to access the account. Threat 7 An attacker prevents the customers from accessing their accounts. Threat 8 An attacker tries to move money from an account to their own (legitimate) account. Relating threats to use cases provides a systematic and relatively complete list of possible threats. Each threat identified can be analyzed to see how it can be accomplished in the specific environment. The list can then be used to guide the design and to select security products. It can also be used to evaluate the final design by analyzing whether the system’s defenses can stop all these attacks. Since use cases define all the interactions with the system, we can find from them the rights needed by these roles to perform their work (the need-to-know principle).
In the activity diagram in Figure 16.2 the threats are shown as misuse actions. Undesired consequences in the form of additional or alternative artifacts created have also been added. With these annotations, the attacks and vulnerabilities presented by the use case become part of our understanding of the use case and are explicit in its analysis.
From our analysis we can now find out what policies are needed to stop these attacks. For this we can select from the typical policies used in secure systems [Fer13]. This should result in a minimum set of mechanisms, instead of an approach in which mechanisms are piled up because they might be useful. For example, to avoid imposters we can have a policy of identification and authentication (I&A) for every subject participating in a use case.
To stop the threats in the example on page 443, we need the following policies:
Threat 1, 3. Mutual authentication. Every interaction across system nodes is authenticated. Threat 2. Verify source of information. Threat 4. Logging. Since the manager is using his legitimate rights, we can only log his actions for auditing at a later time. Threats 5, 6. Separation of administration from the use of data. For example, a manager can create accounts, but should have no rights to withdraw from or deposit in the account. Threat 7. Protection against denial of service. We need some redundancy in the system to increase its availability. Threat 8. Authorization. If the user is not explicitly authorized, they should not be able to move money from any account. We made this approach more systematic in [Bra08a]. We believe that this approach can produce all the attacks that can be defined at the application level. There is a trade-off between cost, usability and acceptable level of risk. Finding the right mix for your application involves a risk analysis. In our use case approach, we identify risks as an integral part of the use case’s definitions. Vulnerabilities are combined with specific actors and their motivations. In the analysis phase we match security breaches with defense strategies using patterns. Because the vulnerabilities, and corresponding defenses, are an integral part of both structural and functional views, the consequences of specific security failures can be analyzed in the appropriate context. Risk analysis is better supported than in methodologies that lacks these views.
16.2 The Analysis Stage We proposed a new type of analysis pattern, called a semantic analysis pattern (SAP) [Fer00]. A semantic analysis pattern is a pattern that describes a small set of coherent use cases that together describe a basic generic application. The use cases are selected in such a way that the application can fit a variety of situations. Using SAPs we developed a methodology to build the conceptual model systematically. To use the methodology, it is necessary to first have a collection of patterns, such as those in this book. We have developed several analysis patterns, for example [Fer99a] [Sor04] [Sor05] [Yua03], and others exist in the literature, for example [Fow97] [Ham04].
We can use SAPs as part of our secure system development methodology. We extend the SAP to consider possible attacks to the fundamental use cases that define it, and we define policies to prevent the attacks. This is the application of an idea proposed in [Fer06c] which emphasizes that the secure design of a system should be based on its expected types of attacks. Since the SAPs are used to build the conceptual model of an application, we have now a portion of a conceptual model in which functional and security aspects are integrated from the start. We call this a secure semantic analysis pattern (SSAP). As an example, Section 16.4 (page 451) describes a SSAP to handle legal cases. SSAPs follow the current tendency in security research of integrating business functions with security aspects from the beginning of the development lifecycle [Nag05] [Sch06a].
It is possible to superimpose in the SAPs the authorizations that are required to apply a least privilege policy. The use cases define all the ways to use the system, and we need to give the actors involved the rights they need to perform their interactions [Fer97]. We will illustrate these concepts using a medical application (another medical application is described later in this chapter).
Figure 16.3 shows a sequence diagram that implements the use case ‘Admit a new patient’ when a medical center gets a new patient. The ‘Admit a new patient’ use case is an interaction with a medical system in the PATIENT TREATMENT RECORDS pattern described on page 468. An administrative clerk needs rights to define a guardian and to create a patient record, patient information, a medical history and a treatment instance. We can add authorization rules to perform these functions to the PATIENT TREATMENT RECORDS pattern by adding instances of some security policy.
Figure 16.3: Sequence diagram for the use case ‘Admit a new patient’
One of the most basic security policies is that defined by the ROLE-BASED ACCESS CONTROL (RBAC) pattern (page 78). In this model users join roles according to their tasks or jobs, and rights are assigned to the roles. In this way a need-to-know policy can be applied, in which roles get only the rights they need to perform their tasks (see Chapter 6).
As an example of our approach, we add RBAC constraints to the SAP mentioned earlier. The PATIENT TREATMENT RECORDS pattern describes the treatment or stay instance of a patient in a hospital [Sor04]. The hospital may be a member of a medical group. Each patient has a primary physician, an employee of the hospital. Upon admission the patient record is created, or information is updated from previous visit(s). Inpatients are assigned a location, nurse team and consulting doctors. This pattern realizes use cases ‘Admit a new patient’, ‘Discharge patient’, ‘Assign assets to an inpatient’, and ‘Assign nurse to a location’. Assets of the medical group are assigned to a patient through associations. Figure 16.4 shows associations between the classes Doctor, Nurse and Location and the class Patient, which describe the corresponding assignments. In particular, all patients are assigned a primary doctor, while inpatients may also be assigned consulting doctors. Locations include the room assigned to an inpatient, or other places for specific treatments.
Figure 16.4: Class diagram for the PATIENT TREATMENT RECORDS pattern
The assets of the medical group are organized in a hierarchical arrangement that describes their physical or administrative structure. Specifically, MedicalGroup includes some Hospitals, and in turn each Hospital includes some Buildings (we assume that hospitals do not share buildings). Each treatment Location is part of a Building. The class Employee classifies the types of personnel that are assigned to patients. Figure 16.5 superimposes RBAC rights on some of the classes of Figure 16.4, indicating rights for several roles. We have now an SSAP that, in addition to being a unit for building a conceptual model, also indicates the typical roles that would perform its use cases, and their rights.
Figure 16.5: PATIENT TREATMENT RECORDS pattern with RBAC authorizations
16.3 The Design Stage We can now carry over the security architecture of the analysis stage to the design stage. One approach to enforcing security constraints is to use a Model-View-Controller (MVC) pattern [Bus96]. Each View corresponds to an interface for a use case, and we can enforce role rights at these interfaces. Figure 16.6 (page 450) implements the use case ‘Admit a new patient’ and shows the AdministrativeClerk role to be the only role with the ability to admit patients and perform the required actions.
Figure 16.6: Adding security enforcement through interfaces
A design model can be made more specific by specializing it for a particular language. For example, it could be tailored for Java and J2EE components by using the classes Observable (instead of Model), Observer and Controller from the Java libraries. It is also possible to define rights in J2EE components. This security is specified in the deployment descriptor that is written in XML [Kov01]. Security in J2EE is based on roles and matches the model we are using well. For example, if the Patient class is implemented as a component, its descriptor may specify that TreatmentInstance can only be modified by doctors. This rule is at a lower level than interface rules and could not be overridden – that is, no rule in the AdmitPatientView can give somebody who is not a doctor the right to modify patient treatment instances. This approach adds a second line of defense against administrator errors (the defense in depth principle). Similarly, components can access persistent data in relational databases using JDBC. These relations could include further authorizations to provide another line of defense. When we do this, it is necessary to make sure that the rights defined in the views, components and database items do not conflict with each other. To determine possible conflicts, we need to map security constraints across architectural levels [Fer99b].
Distribution provides another place to perform access control and it needs again to be coordinated with the other authorizations. Distribution is usually performed through three basic approaches:
Distribution of objects using an Object Request Broker, such as CORBA, DCOM or .NET Remoting. We can add security rules to the Broker pattern to control access to remote objects. Distribution of component and interfaces, for example web services. We can control access to web services using an access control standard such as WSPL (page 260) and enforce it using an XML FIREWALL (page 242) [Del04]. Cloud computing. Services are provided by the three major layers of a cloud system [Zha10]. Experience has shown that a good way to build dependable systems is to structure them into a set of hierarchical layers. Some important issues for hierarchies are what functions to include in each layer, and how much security is needed in each layer to accomplish an intended level of security for the whole system. Not all layers need be equally secure; the lower levels are more critical and need stronger protection. Security and other non-functional requirements affect all the architectural levels of a system. The Layers architectural pattern [Bus96] [Fer02] is therefore a good starting point to apply these requirements. Using layers we can define patterns at all levels that together implement a secure or reliable system. The main idea of the Layers pattern is the decomposition of a system into hierarchical layers of abstraction, in which the higher levels use the services of the lower levels. Earlier we discussed why all these levels must be coordinated to assure security [Fer99b] and how the definition of non-functional specifications should be done at a specific level [Fer95].
The conceptual enterprise models, both static and dynamic, are defined at the application level. It is here where the security (and other types of) policies of the institution should be applied. At this level the semantics of the application are well understood and roles can be used to apply the need-to-know policy; that is, we can define the required rights according to the functions of each role. Other non-functional aspects are also specified here, such as the required degree of reliability. The lower levels enforce the restrictions defined at the higher levels. Each level has its own security mechanism and should participate in enforcing the security constraints. For example, a DBMS enforces the authorizations in the application by restricting access to database items; this restriction is propagated down to control access to the files where the data resides.
16.4 Secure Handling of Legal Cases This is an example of an SSAP which shows an application of the patterns in building a secure semantic unit that includes a set of basic functions from the same application domain. The SSAP describes the handling of legal cases in which a client is either suing another party (a plaintiff) or is being defended from a suit (a defendant) using a legal firm. The pattern includes the necessary policies (in the form of security patterns) to stop or mitigate attacks.
EXAMPLE The SueThem law firm is having trouble staying in business. It keeps some documents in electronic form and others on paper. Documents are hard to find and can easily be accessed by unauthorized people. It is hard for the company to keep track of their clients and to know how much it should charge them. The conduction of cases is disorganized, which leads to lost cases because of lack of preparation.
CONTEXT A legal firm sues parties (people, organizations or groups) on behalf of their clients; it can also defend their clients when they are sued. We call a legal case the sequence of actions (process) needed to pursue a suit until its completion. The standard legal system of most countries allows parties to sue other parties. There are different types of lawsuits, but they are not of interest here. Interactions between the people involved can be in person, by telephone, by regular mail or by e-mail. Law firms are commercial entities and must compete with other law firms for clients.
PROBLEM A law suit or defense implies a sequence of actions and generates many documents, of several types. If the firm doesn’t organize these actions and the corresponding documents properly, it will have problems in conducting the suit or defense, which will result in unnecessary expenses and a higher possibility of losing the case. Because the information handed in a case is very sensitive, there is motivation to misuse it.
We need to consider possible attacks and take measures to avoid them. We consider here the main use cases in this process: ‘Handle legal case’ (for a plaintiff), ‘Handle legal case (for a defendant)’, and its auxiliary use cases ‘Keep track of costs’, ‘Research case’, and ‘Bill Client’. Figure 16.7 shows the actors involved in these use cases. ‘Other’ here represents people involved in the case, such as witnesses or experts. There are other related use cases, such as the writing of Wills, or divorce cases, which are left out for simplicity and to make the pattern more reusable.
Figure 16.7: Use cases for handling legal cases
How can we model this system to consider all these factors in a balanced way? The solution to this problem must resolve the following forces:
Unpredictability of activities. The sequence of activities in a case is usually unpredictable. Depositions, witness court appearances and lawyers’ briefs to the court might be required in any sequence, depending on the course of the case. Unpredictability of people. Complex cases may require several lawyers with the assistance of some secretaries. The actual number of these people might be hard to predict. In addition to the defendant and the plaintiff (and their respective opponents), we may need witnesses, experts and others. Who they are and when they are needed depends on the case. Logistics. The total effort and duration of a case is variable, and we need to keep track of expenses, time used, supplies and so on, so that we can bill our clients. Precedent searching. Handling cases requires searching for precedents (similar cases). To do research for cases, lawyers and secretaries make use of libraries and the Internet and may download many documents. Access control to information. The information about customers, billing, assignment of lawyers and other aspects related to a current case must be accessible only to authorized people. Control of documents. Legal documents can only be created by authorized people, and their use (reading or modification) should also be controlled. Confidentiality. Communications between lawyers and clients must be confidential. Auditability. Government regulations apply to law firms and their information must be easily auditable. POSSIBLE ATTACKS Figure 16.8 shows an activity diagram of the sequence for handling a case, followed by billing, tracking of costs and related case research. Following the approach of [Fer06c], in order to analyze the possible attacks (threats) we consider each activity in the activity diagram and see how it can be subverted by the attacker. In this diagram External People indicates either the opponent or other people involved in the case. The possible threats are then:
Figure 16.8: Activity diagram of case handling
Threat 1 In the ‘Start Case’ activity, the client or the responsible lawyer might be imposters. Threat 2 A lawyer might create a false contract. Threat 3 The client or the external people might give a false deposition. Threat 4 A lawyer might change a deposition. Threat 5 A lawyer or a secretary might produce intentionally incorrect precedents, briefs or costs. Threat 6 A secretary might produce an increased or decreased bill. Threat 7 A lawyer might change some aspects of the outcome to collect a higher fee. Threat 8 A lawyer can disseminate client or case information for monetary gain. Threat 9 An external attacker might read/change case information or access client/lawyer communications. SOLUTION Because the handling of cases is unpredictable and we use a variety of knowledge experts in its handling, this problem can be conveniently modeled as a Blackboard pattern [Bus96]. The case itself becomes a blackboard and the experts providing knowledge to the case are the lawyers, witnesses or experts. The control is based on the status of the case and is embodied in the scheduling of activities.
STRUCTURE Figure 16.9 shows a class diagram of the conceptual model for the functional aspects of this pattern. The class Case represent the case itself (in the role of blackboard), and includes as components the classes Cost (describes accrued costs), CaseDoc, Outcome (the result of the case) and Scheduling (the control role of the blackboard). A Client is responsible for a case, and with each case there are some associated ExternalPeople (opponents, witnesses, experts). A CaseDoc can be a Contract, a Precedent, a Brief or a Deposition. Lawyers and Secretaries are Employees of the LawFirm and can be assigned to Cases (we assume this assignment has been done beforehand). A Secretary in the Case keeps track of Costs. A Lawyer in the case is responsible for the general conduction of the case, including Scheduling.
Figure 16.9: Class diagram for the SECURE HANDLING OF LEGAL CASES (without security)
DYNAMICS Figure 16.10 shows a sequence diagram describing some typical steps for the use cases ‘Handle legal case (for a plaintiff) and ‘Handle legal case (for a defendant)’. The Client starts the case with the responsibleLawyer. This lawyer creates an instance of a Case and later does some research for it. He assigns an assistant lawyer (lawyer2) to prepare a Brief for the court and schedules the client to make a Deposition.
Figure 16.10: Sequence diagram for the use case ‘Handle case (etc.)’
The other use cases are simpler and are not shown for conciseness.
SECURE STRUCTURE The threats identified on page 453 mean that we need the following policies to avoid or mitigate them:
Threat 1 Mutual authentication, to avoid imposters. Threat 2 Authorization to restrict lawyers to the creation of contracts, and logging to record possible illegal actions by a lawyer. Threat 3 Logging, to keep records for future auditing that could detect false depositions. Threat 4 Authorization and document protection against change. Threat 5 Authorization and logging, to restrict who can perform these actions, and to keep records for future auditing. Threat 6 Logging, to record suspicious actions by a secretary. Threat 7 Separation of duty: two lawyers must concur on the fees to be charged. Threat 8 Logging, to record possible illegal actions by lawyers. Threat 9 Authorization and access control, to stop external attacks, and cryptography, to protect communications. From these policies we can define abstract security mechanisms to stop or mitigate the identified attack threats. Figure 16.11 shows the relevant part of the conceptual model of Figure 16.9, with the addition of instances of authentication, authorization and logging patterns to realize the identified policies. We assume that the authorization policies follow an RBAC model (see page 78) and the diagram defines the rights for each role. Both the responsible lawyer (who interacts with the client), and the client must have information to authenticate each other, requiring two instances of the AUTHENTICATOR pattern (page 52). The CaseLog (an instance of the SECURITY LOGGER AND AUDITOR pattern, page 111) records accesses to the case data. We also need an instance of the REIFIED REFERENCE MONITOR (page 100), not shown here for simplicity.
Figure 16.11: Security additions to the class diagram
EXAMPLE RESOLVED The SueThem law firm now has a systematic structure to conduct its cases. All its documents are reflected in the conceptual model and can be easily retrieved and audited. The company can now keep track of the costs associated with a case. Documents and other case information can be protected from illegal access.
CONSEQUENCES The SECURE HANDLING OF LEGAL CASES pattern offers the following benefits:
The Blackboard structure accommodates unpredictable sequences of activities well. We can assign lawyers and secretaries dynamically, depending on the course taken by the case. The model includes knowledge sources that can be the client, the opponent, witnesses, expert witnesses and other people. It is possible to track the current costs of the case. Applying legal regulations to the company is easy, because all documents are described by classes with controlled access, and we keep a log of accesses. Searching for precedents (similar cases) can be done as part of case handling. We can store this information for future use, and we can associate it with the different stages of the case. The pattern also has the following potential liabilities:
The order in which some activities are performed has an effect in the outcome, but the lawyers must decide on the scheduling: the pattern does not help here. We might not be able to predict all possible attacks, which could allow some attacks to still happen. The pattern’s implementation might allow new types of attacks. For example, code flaws might allow an attacker to get control of the operating system, and thus to the case data. Application of this pattern has the following effects on security:
We can define precise role rights. For example, an expert can only add to case information, not change it, a lawyer can decide on the next step, bring new witnesses, but cannot change depositions, and so on. A designer building a system of this type can produce software that performs its functions and is at the same time reasonably secure, in that it can control all predicted threats. The ROLE-BASED ACCESS CONTROL structure (page 78) enforces authorized access to the information, and employees can make sure that they are communicating with the person they intend to. Cryptographic methods such as hashing [Gol06] can be added to prevent document modification. KNOWN USES Many large law firms follow a similar structure for their case handling.
SEE ALSO The SECURE BLACKBOARD pattern (page 353) is the basis for the central function of the case. The client and external people can be described by a Party pattern to indicate that they can be individuals or organizations [Fow97]. Assignment of lawyers and secretaries uses the Resource Assignment pattern [Fer05h]. The rights structure follows an ROLE-BASED ACCESS CONTROL pattern (page 78). Authentication is performed by means of instances of the AUTHENTICATOR pattern (page 52). 16.5 SCADA Systems Infrastructure systems are needed to sustain civilized life. These include transportation, finance and banking, government, chemical, energy, oil and gas production and distribution, health services, information management, water (for drinking and irrigation), emergency services (fire, police), garbage collection and others. All these infrastructure functions are controlled by systems that are complex and becoming increasingly interdependent: each system typically depends on one or more other systems. Some are mutually dependent; for example, electric power generation may require oil, and oil production will require electricity.
Modern industrial facilities such as water supply systems, electric power generation plants and oil refineries often involve components that are geographically distributed. To continuously monitor and control the different sections of the plant in order to ensure its appropriate operation leads to the use of Supervisory Control and Data Acquisition (SCADA) systems. These systems were designed to meet the basic requirements of process-control systems for which security issues were not a concern. However, the growing demands for increased connectivity between a SCADA system and other network components, such as the corporate network and the Internet, expose the critical parts of a SCADA system to the public, so security issues can no longer be ignored. In fact, some attacks have already been detected [Bra08b] [Byr04]. Here we consider the use of security patterns to define, in a systematic way, the defenses that we need in order to secure such a system. While many approaches to secure SCADA systems exist, for example [Bra08b] [Goe05] [Igu06] [Mil05] [Nae07], none of them make use of security patterns.
Basically, a SCADA system consists of field units, a central controller, and communication networks that connect these components. A field unit consists of field devices and a local programmable logic controller (PLC). Field devices, such as actuators and sensors, are monitored and controlled by a local PLC. The central controller is generally geographically separated from these field units and typically has advanced computation facilities. A typical central controller may be equipped with data servers, human-machine interface (HMI) stations, and other servers with advanced computation capabilities to aid the operators in managing the entire plant.
Figure 16.12 is a class diagram for a basic SCADA architecture. The functions of the central controller include sending settings and commands to field units and receiving status information from them. The functions of the field units include monitoring the environment, taking actions on the environment and sending status information and/or alarms to the central controller if necessary. The functions of the communication networks include forwarding data and commands in both directions.
Figure 16.12: Class diagram for a generic SCADA system
Modern SCADA systems are normally connected to the corporate networks and/or the Internet through specialized gateways. The gateway is used to provide protocol conversion between two different networks when they use different protocols. The MODBUS protocol is currently one of the most popular and widely-used protocols with SCADA systems [Goe05], but other protocols are used for specialized applications. Since SCADA systems have a standard structure, we devised a specific pattern to define and model them. Figure 16.12 describes the static structure of this pattern.
SECURING A SCADA SYSTEM We propose a method to analyze, build and evaluate secure SCADA systems using security patterns. Intuitively, we use security patterns to stop and/or prevent attacks, and we list these attacks first. The result of our solution is a security pattern itself (an SSAP) the SECURE SCADA pattern, which can be used as a guideline for building secure SCADA systems. All the required patterns were described in Chapter 5, Chapter 6 and Chapter 10.
ATTACKS AGAINST SCADA SYSTEMS Until recently SCADA systems were electronically isolated from all other networks, and hence not likely to be accessible by outside attackers [Bra08b]. As a result, the security issues of a SCADA system focused on physical security, such as physical access control. However, the growing demands of the industry for increased connectivity between SCADA system and the corporate network (and/or the Internet) has resulted in an increase in security threats and vulnerabilities that are not limited to physical attacks [Gor09]. A recent study shows that prior to 2000, almost 70% of the reported incidents with SCADA systems were either due to accidents or to disgruntled employees acting maliciously. Since 2001, apart from an increase in the total number of reported incidents, almost 70% of the incidents have been due to attacks originating from outside [Byr04].
We can systematically enumerate the threats against a system by considering its use cases and activities, and analyzing possible ways of subverting them. A simplified version of our approach is to look at possible attacks against each unit of the system, providing that its platform structure is predefined. This is a preliminary enumeration of threats, which can be expanded at a later stage of design. Note that these threats include external and internal attacks.
Recalling Figure 16.12, a generic SCADA system is mainly composed of a central controller, communication networks and field units, so we can categorize threats corresponding to these three components. Attacks against/through the central controller include:
Threat 1 Physical attacks. Threat 2 Malicious settings of the field units. Threat 3 Wrong commands sent to the field units. Threat 4 Malicious alteration of the runtime parameters of the central controller. Threat 5 Denial of service attacks. Attacks against/through the field units include:
Threat 6 Physical attacks. Threat 7 Malicious alteration of the runtime parameters of the field units. Threat 8 Incorrect commands sent to the field units. Threat 9 Malicious alarms sent to the central controller. Threat 10 Denial of service. Attacks against/through the communication networks include:
Threat 11 Sniffing. Threat 12 Spoofing. Threat 13 Denial of service. Attacks against the central controller and the network are more harmful, since they may disable the whole system, whereas attacks against field units only affect specific units. For simplicity we are leaving out attacks due to malware, which can be handled using conventional approaches.
COUNTERMEASURES Central Controller
To stop Threat 1, we use security patterns for physical access control such as the ROLE-BASED ACCESS CONTROL pattern (page 78) combined with the AUTHENTICATOR pattern (page 52) and the SECURITY LOGGER AND AUDITOR pattern (page 111). To stop Threats 2, 3 and 4, we use the AUTHORIZATION pattern (page 74) together with the AUTHENTICATOR pattern and the SECURITY LOGGER AND AUDITOR pattern. The AUTHENTICATOR restricts access to the system to registered employees, while the AUTHORIZATION pattern controls the actions that the employees can perform on the controller. The SECURITY LOGGER AND AUDITOR pattern is useful for those cases in which a legitimate employee is trying to perform sabotage (we cannot stop the attack, but we have a record of who did it). To stop Threat 5, we use the Firewall pattern [Sch06b] together with an Intrusion Detection System (IDS) pattern (Chapter 10). The IDS detects the attack and instructs the firewall to block traffic from the attacking addresses. Note that the Firewall and the IDS patterns can be deployed at different layers of a system (for example the application layer and the network layers). Figure 16.13 shows the class diagram for the secure central controller after the necessary security patterns have been applied. Note that the users’ actions are controlled at the HMI, which acts as a Concrete Reference Monitor [Sch06b] for user interactions: it can apply authorization controls based on user roles. Figure 16.13: Secure central controller where security patterns are applied
FIELD UNITS To stop Threat 6, we use the ROLE-BASED ACCESS CONTROL pattern (page 78) combined with the AUTHENTICATOR pattern (page 52) and the SECURITY LOGGER AND AUDITOR pattern (page 111). We use the AUTHORIZATION pattern (page 74) together with the AUTHENTICATOR pattern and the SECURITY LOGGER AND AUDITOR pattern to stop Threats 7, 8 and 9. By applying the Firewall pattern together with the IDS pattern, we can stop Threat 10. Figure 16.14 shows the class diagram for the secure field unit after necessary security patterns have been applied. Figure 16.14: Secure field unit after security patterns have been applied
COMMUNICATION NETWORKS To stop Threat 11, we use cryptography-based methods such as secure channels [Bra00]. To stop Threat 12, we use the AUTHENTICATOR pattern (page 52) to prove the origin of a message. In practice, we can implement the above mechanisms using virtual private networks (VPN). Stopping Threat 13 is out of the scope of this pattern: see Chapter 10. Figure 16.15 shows the class diagram for the secure communication networks where necessary security patterns are used. Figure 16.15: Secure communication networks after security patterns have been applied
SECURE SCADA Note that the structure of the class diagram in Figure 16.13 is similar to that in Figure 16.14. This is due to the fact that the central controller and the field units are exposed to similar attacks. As a result, we can produce the SECURE SCADA pattern, which combines these figures, as shown in Figure 16.16.
Figure 16.16: Class diagram for the SECURE SCADA pattern
An important aspect in the protection of SCADA systems is controlling access to their physical structures, for example the transformer yard in an electric plant. The recently increased need to protect against terrorism has brought added interest in control of access to buildings and other physical structures. The need to protect assets in buildings and to control access to restricted areas such as airports, naval ports, government agencies and nuclear plants has created a great business opportunity for the physical access control industry, and much interest in the research community. One of the results of this interest has been the recognition that access control to information and access control to physical locations have many common aspects.
The most basic model of access control uses a tuple: subject, object and access type (Chapter 6), or ‘S’, ‘O’ and ‘T’. If we interpret S as a person (instead of a subject), O as a physical structure (instead of a computational resource), and T as a physical access type (instead of resource access), we can make an analogy where we can apply known results or approaches from information access control. One way to achieve this unification is to use a conceptual abstraction for the definition of security requirements. We have combined analysis and security patterns for this purpose [Fer05g]. Standards and products that deal with physical units use a set of common concepts that may appear different due to a different notation; patterns make this commonality apparent. Examining existing systems, industry standards and government regulations, we have described, in the form of patterns, the relationship and definition of a core set of features that a physical access control system should have [Fer07f].
16.6 Medical Applications The Internet, wireless systems and RFID sensors are opening a new era in medical care. Most activities in medical care can be integrated and performed remotely and pervasively. This change promises to improve medical care and reduce costs. However, if these systems are not secure, users will lose confidence in them and some of their advances will not be realized. We discuss here some relevant issues, and emphasize again that to have secure systems we must consider security from the beginning, in all phases, and in the whole system. (Another medical application using patterns is shown in [Paz04].)
The so-called telehealth applications include assisted living, pervasive healthcare, patient monitoring, distance surgery, remote diagnosis, ambulance and others; they all typically rely on wireless networks. Because of their need to be established over long distances and to often operate without supervision, these networks are exposed to a variety of attacks. We look at some medical applications and the corresponding network security issues. In particular, we consider here aspects of mHealth (also written as m-health, or sometimes mobile health), a recent term for medical and public health practice supported by mobile devices such as cellular phones, patient monitoring devices, PDAs and other wireless devices [Jur08]. Applications of mHealth include the use of mobile devices for collecting clinical data, delivery of healthcare information to practitioners, researchers, and patients, real-time monitoring of patients’ vital signs and direct provision of care (via telehealth). We consider mHealth not to be a set of independent systems, but merely a complementary part of the complete medical system.
Most discussions of the security of wireless networks for health applications consider only the communication aspects of the networks, for example [Gia08] [Zen08]. However, a health network is part of a complete health application, and we need to relate its communication aspects to its medical aspects. We need to understand first what information is needed for medical purposes and how this information is used. Once we define what information we need, we present a pattern for patient records management. Then we show a case study, ambient assisted living, followed by an analysis of the threats and defenses in a wireless network such as the ones used in medical applications.
MEDICAL RECORDS AND THEIR REGULATIONS The electronic healthcare record (EHR) is a lifetime record of an individual that has the purpose of supporting continuity of care and related education and research. It typically includes information about encounters (visits), lab tests, diagnostics, observations, medications, imaging reports, treatments, allergies and therapies, as well as patient-identifying information and legal permissions [Eic05].
Medical information is very sensitive and must be protected. Most countries have severe restrictions in the use of this information. There are several regulations in the US about the handling of health information, the best known being the Health Insurance Portability and Accountability Act (HIPAA) [HIP] [Hip]. Title II of the HIPAA, known as the Administrative Simplification (AS) provisions, requires the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans and employers. The AS provisions also address the security and privacy of health data. The standards are meant to improve the efficiency and effectiveness of the nation’s health care system by encouraging the widespread use of electronic data interchange.
Five rules define Administrative Simplification:
The Privacy Rule regulates the use and disclosure of specific information held by covered entities (healthcare providers, health care clearing-houses, employer sponsored health plans and health insurers) and their business associates (lawyers, accountants, IT consultants). It establishes regulations for the use and disclosure of protected health information (PHI). The Transactions and Code Sets Rule defines specific transaction types. For example, the EDI Health Care Claim Transaction set (837) is used to submit health care claim billing information, encounter information, or both (except for retail pharmacy claims). It can be sent from providers of health care services to payers, either directly or via intermediary billers and claims clearing-houses. The Security Rule complements the Privacy Rule. While the Privacy Rule pertains to all PHI, including paper and electronic media, the Security Rule deals specifically with electronic protected health information (EPHI). It lays out three types of security safeguards required for compliance: administrative, physical and technical. The Unique Identifiers Rule establishes that providers must use only the National Provider Identifier (NPI) to identify themselves in standard transactions. The NPI is a unique 10-digit identification number provided by the US Government. The Enforcement Rule sets civil financial penalties for violating HIPAA rules and establishes procedures for investigations and hearings for violations. It seems to be rarely applied, however. Privacy is the right of individuals or groups to keep their personal information away from public knowledge, or their ability to control personal information flow. In the electronic or the real world, people seek privacy, so they can perform their actions without others monitoring them. Individuals should be able to live without being disturbed, and users interact with the web navigate without being identified. People providing information to medical institutions or storing their personal records with commercial companies should know what to expect about the privacy of their information. This right is recognized by all civilized societies and is considered a fundamental human right. The first national privacy protection law was the Swedish Data Act of 1973. This was followed by the US Privacy Act of 1974. The intent of this act was to protect individuals against invasion of privacy by the Federal Government. This law is complemented by the Computer Security Act of 1987, which defines requirements for federal agencies concerning the security of their information. In general, privacy laws are more developed in Europe than in the US.
PATIENT TREATMENT RECORDS We present a pattern to describe some of the basic functions involved in maintaining and using patient records in a hospital, the Patient Treatment Records pattern [Sor04]. A medical record can be thought of as a series of dated treatment instances, or encounters. Each patient encounter is documented on a patient chart and contains dated notes written by physicians, as well as laboratory reports and letters from consulting physicians. In addition, a patient chart will have vital sign documentation from nurses, imaging reports, specific treatment plans, treatments performed, medications given, assessments of patient condition and so on.
The PATIENT TREATMENT RECORDS pattern focuses on the private and sensitive nature of medical information and the need for maintaining accurate and organized records. A patient is admitted to a healthcare facility, where all pertinent information is recorded. A physician and other facility assets are assigned to the patient. Following treatment the patient is discharged. This pattern describes only some of the aspects of patient treatment, which include the creation and maintenance of the patient record and the assignment of the assets for use by the patient. This pattern describes a general non-emergency treatment situation and does not consider the details of patient diagnosis and treatment.
The pattern describes the handling of records during the treatment or stay instance of a patient in a hospital. The hospital may be a member of a medical group. Each patient has a primary physician, an employee of the hospital. Upon admission the patient record is created or information is updated from previous visit(s). Inpatients are assigned a location, nurse team and consulting doctors.
The PATIENT TREATMENT RECORDS pattern is another example of a semantic analysis pattern (SAP). In the next section we describe one of its two component patterns, the PATIENT RECORD. The other two component patterns can be found in [Sor04], and a more detailed model for medical records in [Sor05]. Figure 16.17 shows a use case diagram that corresponds to some of the typical needs of patient treatment which define the structure of the PATIENT TREATMENT RECORDS pattern. There are other use cases, such as ‘Diagnose’, ‘Perform patient treatment’, and ‘Billing’, which have been omitted for simplicity.
Figure 16.17: Diagram of the use case ‘Patient treatment’
PATIENT RECORD Describes the structure of patient records and the process of creating and maintaining them for a stay or treatment in a hospital.
PROBLEM Maintaining accurate records is crucial for patient treatment. A poor record may result in erroneous treatments, loss of insurance or other problems for the patient or the hospital. How can we keep an accurate picture of what happens during the stay of a patient in a hospital?
The solution to this problem must resolve the following forces:
Patient characteristics, for example age, gender, occupation, ethnic or racial origin, weight and others, may have an effect on the diagnosis and treatment of the patient, and it is important to keep this information accurate. We need a detailed record of what has been done to a patient during a specific stay at the hospital. This is necessary for medical, billing and legal reasons. Patients may return to the hospital, so we need to be able to relate new treatments to past treatments. We may need to classify different types of patients, otherwise the patients or the hospital might incur unnecessary expenses. Patients might not be responsible for their decisions or their expenses, so we may need somebody responsible for the patient. The information is sensitive and we need to add security measures. SOLUTION Maintain a medical history for each patient. This medical history typically contains insurance information and a record of all treatments within the medical group. If the patient is new to the medical group a patient record and medical history will be created upon admission. If the patient has been treated in any facility within the medical group there will be an existing patient record and a medical history, which may need to be updated. A treatment instance is created for all patients admitted and updated throughout the patient’s stay. The treatment instance will subsequently be added to the patient’s medical record upon discharge. A person or guardian is responsible for each patient. We classify patients into inpatients and outpatients. Use cases realized by this pattern include ‘Assign a guardian’, ‘Modify medical history’ and ‘Admit a new patient’ (Figure 16.3, page 446).
Figure 16.18 shows the class diagram for this pattern. A unique stay or TreatmentInstance for every Patient is created upon admission to the hospital. The Patient may be admitted to the hospital as an Inpatient to stay in the hospital, or they may be admitted as an Outpatient, in which case they will receive treatment but will not stay at the hospital. The treatment instances are collected into the MedicalHistory. A Guardian is responsible for each patient. The Guardian can be seen as a role, in that a Patient may be their own guardian. Additional relevant patient information is recorded into PatientInfo.
Figure 16.18: Class diagram for the PATIENT RECORD pattern
We can model other aspects of patient treatment similarly. The remainder of this pattern and the two companion patterns can be found in [Sor04]. These use cases don’t specify design aspects: some of them, for example, ‘Discharge patient’, could be performed from wireless devices. Security can be added similarly, as shown in the next section for ambient assisted living.
AMBIENT ASSISTED LIVING Ambient assisted living (AAL) defines architectures for home environments which have devices such as sensors and cameras to support and monitor people with impaired functions or disabilities. Assisted living requires a secure infrastructure of services to be in place at the patient’s home or place of care. Many of these services are also valuable for family living and the corresponding architectures differ mostly in the specific types of services they provide [Suo08].
An assisted living system has the following requirements [Wan06]:
Dependability. Critical services should be delivered in spite of failure of useful but non-critical services. Moreover, the system as a whole should have high availability and robustness. Low cost and flexibility. The general infrastructure should be open with well-defined interfaces, machine-checkable QoS assumptions, and support the use of low-cost third-party devices. Security and privacy. Medical and personal data should be protected with different rights for different roles (health care providers, medical team, relatives and assisted people). The complete network architecture must be secure. Quality-of-service provisioning. Quality of service (QoS) should be provided at different levels, depending on the level’s criticality requirements. Open standards. Any brand or type of device should be able to interoperate with any devices and operating systems. Lightweight, easy-to-use HCIs. The user interfaces should be easy to use, safe, tolerant of user mistakes, and provide different control levels of information disclosure. Flexibility. Hardware architectures and software should be adaptable and extensible. Interoperability. Compatibility with electronic healthcare records (EHR) is needed, so that the same concepts appear in the information stored and propagated by the devices. Some possible use cases are listed below [Wan06]. We are converting these into patterns, and we show some UML models for them.
Use Case: Remind of Activity – Figure 16.19, Figure 16.20 Figure 16.19: Class diagram for the AMBIENT ASSISTED LIVING pattern
Figure 16.20: Activity diagram for the use case ‘Remind of activity’
The health provider obtains updated prescription and appointment records of the assisted person (AP) from a dedicated server (to which health care providers have access) through secure channels. When it is time for the AP to carry out their time-driven routines, such as taking medicine or monitoring vital signs, the health provider locates active wireless-enabled devices (for example televisions, cellphones, wearable headsets or active badges) within range, and sends reminder messages to one or more devices that are in the proximity of the AP. (The AP can also prioritize the order in which devices will be used.)
For example, if the AP is watching television at the time when the reminder message is scheduled, the TV will be switched to an information channel (with the use of infrared remote control) and a reminder message will be displayed. In this manner, the AP can be reminded of their time-driven routines. Whether or not these routines are followed as advised is detected in a non-intrusive manner by exploiting sensor localization technologies such as RFID: prescription bottles can have RFID tags with unique barcodes, and one or more RFID readers in the environment can be activated (by the health provider) to track location changes (if any) of these bottles. Each RFID tag costs approximately 40 cents today, and the cost is expected to further decrease in the future.
Figure 16.19 shows a class diagram for this pattern, while Figure 16.20 shows a corresponding activity diagram.
Use Case: Vital Sign Measurement In the current practice of glucose monitoring for diabetic patients, a patient measures their glucose level on a daily basis and brings the measuring device to their monthly clinic visits, where the measurements are retrieved and interpreted by health care providers.
With the proposed environment in place, vital signs can be measured and transmitted by Bluetooth-enabled meters to the server. In this fashion, healthcare providers can monitor various vital signs at a convenient time granularity. Should the readings suggest any abnormal health situations, medical instructions can be given before the situation deteriorates.
Use Case: Personal Belonging Localization Personal belongings such as eyeglasses, hearing aids and key chains can be attached with tags and located through the use of RFID readers. When someone cannot find their belongings (because of forgetfulness), they can issue a simple vocal command (through, for example, a lightweight Bluetooth-enabled headset) to the health provider, which then schedules the RFID readers to scan the environment and help locate the object.
Use Case: Personal Behavior Profiling With the same set of sensor localization techniques, the assisted living environment can profile the movement of APs in a privacy-preserving manner (for example without the use of surveillance cameras) and detect early warning signs of depression (no longer taking medicine regularly, giving up routine activities, or staying in bed for long periods of time) and/or other chronic diseases such as Parkinson’s and Alzheimer’s. The AP wears an RFID tag or an active badge, which can be disguised as an item of clothing or jewelry.
Use Case: Emergency Detection In case of the need for emergency attention (for example, dangerously high or low blood pressure or blood sugar levels), or the AP has been detected via localization techniques to be immobile on the floor for an unreasonably long time, real-time communication channels can be established to notify on-site caregivers (in the case of assisted living), health care providers (in the case of clinical use), or designated relatives, and facilitate transmission of electrocardiogram (EKG) data and other measures in real time.
All these approaches require networks, so we next discuss some aspects of network security. Later we’ll discuss the security of sensor networks. These systems are also cyber-physical systems and we should study them as such.
WIRELESS NETWORK SECURITY We consider some aspects of the security of the wireless networks that support these health applications.
WIRELESS DEVICES When compared to wired networks, there are four generic limitations of all wireless devices:
Limited power Limited communications bandwidth Limited processing power Relatively unreliable network connection The bandwidth available to wireless systems is usually an order of magnitude (or even more) less than that available to a wired device. Their processing power is limited, due to limits to space and cost in the case of fixed wireless devices typically used for wi-fi networks, and is further limited due to power constraints in other wireless devices. In general, wireless networks are not very reliable. Protocols have been designed to take this lack of reliability into account and to try to improve it. However, in designing these protocols choices have to be made about the size of the packets and frames to be used. Such decisions can have a profound impact on the effectiveness and efficiency of cryptographic protocols.
To this we must add that security needs for wireless devices are greater than those of regular wired-network devices. This is due to the very nature of their use; they are mobile, they are on the edge of the network, their connections are unreliable, and they tend to get destroyed accidentally or maliciously. They can also be stolen, lost or forgotten. Thus, we need more security processing, but security processing can easily overwhelm the processors in wireless devices. This challenge, which is unique to wireless devices, is sometimes referred to as the ‘security-processing gap’. Non-fixed wireless devices such as cellular handsets and ad hoc network devices such as sensors are also severely handicapped due to their very low battery power. Even though significant advances are expected in computation and communication speed over the next decade, it is still expected that they will lag behind the power available to fixed computers, due to the need for miniaturization.
To make things worse, battery power is only expected to make modest improvements. The battery limitation in mobile wireless devices is sometimes called the ‘battery gap’, and refers to the growing disparity between increasing energy requirements for high-end operations needed on such devices and slow improvements in battery technology. To this we add the fact that there is a large variety of devices using different architectures, several operating systems and diverse functionality. With increase in functions, the typical problems of larger systems are also appearing in portable devices.
THREATS TO WIRELESS DEVICES The analysis of secure systems should start from their possible threats. We can apply our methodology to enumerate the threats to the activities shown in Figure 16.20. We show the threats for two activities; other activities can be analyzed similarly. We then identify policies to stop or mitigate the threats.
These policies can be realized by security patterns, which define the system security requirements and can then be converted into design artifacts, such as secure interfaces. Here the threats appear as attacker goals. When the details of the design start emerging, we can convert these abstract threats into specific threats to the implementation of the components of the system, such as threats to the user interfaces or to the wireless network. This may require adding more security patterns to stop the emergent threats. (A similar analysis is given in [EVI10].)
Activity 1: Remind of activity/task Activity 2: Do activity T11: Control site or patient site is an imposter T21: Unauthorized reading of activity log T12: Unauthorized reading of schedule T13: Unauthorized writing of schedule T22: Unauthorized writing of activity log T14: Denial of service Policies to stop these threats include: P11: Mutual authentication P21: Authorization/access control P12: Authorization/access control P22: Authorization/access control P12: Authorization/access control P12: Cell phone backup GENERAL WI-FI THREATS The attacks described above and for other applications can be realized through other parts of the application, but the wireless network is a source for many of them.
Attacks related to access points (APs) Detection of access points. This is really attack preparation. Tools exist for this purpose, such as Netstumbler. These tools can detect, for each, AP, its MAC address, its location, the transmission channels it uses and the type of encryption it uses. Unauthorized (rogue) APs. An attacker sets up their own AP (malicious association). Once the thief has gained access, they can steal passwords, launch attacks on the wired network or plant malware. Fraudulent APs can easily advertise the same network name (SSID) as a legitimate AP, causing nearby wi-fi clients to connect to them. One type of man-in-the-middle attack is a de-authentication attack. This attack forces AP-connected computers to drop their connections and reconnect to the fake AP. Accidental association. When a user connects to a wireless access point from a neighboring company’s overlapping network, it is a security breach, in that proprietary company information may be exposed, allowing a possible link from one company to the other. Direct endpoint attacks. These take advantage of flaws in wi-fi drivers, using buffer overflows to escalate privilege. Denial of service. This is a common attack in wireless networks because of their frequency sharing with other networks, and can be accidental. A reason for performing an intentional DoS attack is to observe the recovery of the wireless network, during which all of the initial authentication information is resent by all devices, providing an opportunity for the attacker to collect this information. Network injection. The attacker may inject network configuration commands that affect routers and switches. Cryptographic attacks based on message interception. Data sent over wi-fi networks, including wireless printer traffic, can be easily captured by eavesdroppers. Weaknesses in encryption protocols such as WEP can let an attacker read messages. Operating system attacks through the network. Operating systems for wireless devices are becoming more and more complex and attackers can exploit code flaws in them to access their files. GENERAL WI-FI DEFENSES We have discussed earlier how to stop attacks such as the ones enumerated for the ambient assisted living application above. We consider here general approaches to stop attacks on wireless networks. First, a few security principles that also apply to wireless networks:
For new systems, use a global-level design, starting from requirements. Define policies, analyze threats and select defense mechanisms. A methodology like ours is appropriate. Threats can be enumerated. Security must be applied throughout the whole lifecycle and on all architectural levels of the system. Medical records should be integrated with other parts of the hospital, such as lab, pharmacy and so on. A global conceptual model should include all entities relevant to patient care. Due to the sensitivity of data, the system should be a closed system, in which everything is forbidden unless explicitly authorized. System-critical and life-critical functions must have backups. Every access to resources, coming from fixed or mobile devices, should be mediated and checked for validity. There should be no direct access to any data or other resource. For existing systems, perform security auditing. In particular, for the wireless network, we should apply these principles:
The wireless network should be an integrated unit of the whole medical system, not separate units designed or bought independently. All the policies and models that apply to medical records and related information should also apply to the data handled by the wireless network and its devices. The models of all wireless devices should be integrated in a system-wide structure. There should be no outsiders (people, systems) that can access health data. Wireless device usage policies must be consistent with the total system policies. Specific policies for wireless access should at least include:
List those devices authorized to access the wireless network. List the personnel that can access the network. Define rules for setting up wireless routers or APs. Define rules for the use of wi-fi APs, or about connecting to home networks with company devices. Mechanisms such as network access control can be useful to enforce all of the above. Track AP vulnerabilities. It is important to track wi-fi endpoint vulnerabilities and keep the wi-fi drivers up to date. 16.7 Conclusions We can build patterns for sets of related use cases and add security patterns to them to define a secure unit that can be used by an inexperienced developer to build secure applications. To define the security architecture of the network, we need an analysis of the possible threats; security patterns can then be introduced to stop or mitigate them. In this way we can build, for example, secure health systems in an integrated way, including health records, pharmacy records, and other related information, not just isolated wireless networks; the same is true for financial, SCADA, or other types of applications. We have also designed secure architectures for electronic voting [Fer12d] and for homes.