Mark Osborne, in
How to Cheat at Managing Information Security, 2006 Authorization is the process that establishes whether a given identity or subject can
perform a given function against a given object. For example, some user may be authorized to view data, and others may be authorized to delete data; both must be valid users, but they have different capabilities. Authorization or access control is typically defined by access control lists (ACLs). The authorization systems typically fall under several different types: Discretionary
access control (DAC) Here the owner of the system can decide who has access to what and can divulge authority for administration. Mandatory access control (MAC) Here the key thing is that level of access is predefined. The owner cannot change it. This typically means central control. It often means control by privilege levels or security labels (open secret, top secret, and so on), but that is an implementation
detail, not a specification of MAC. Role-based access control (RBACs) With RBAC, a subject is given privilege based on his or her role. This is very similar to the notion of groups in most operating systems; however, such systems usually implement arbitrary rules such as “a subject can have only one active role at a time.” Typically, these are relaxed after implementation, because the key thing is that someone has defined
what type of user should have what type of access.Jargon, Principles, and Concepts
Authorization
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597491105500105
Risk Management Framework Steps 5 & 6
Stephen D. Gantz, Daniel R. Philpott, in FISMA and the Risk Management Framework, 2013
Information System and Environment Changes
The system authorization decision reflects the security posture of an information system in an explicitly defined environment operating at a determined level of risk at a specific point in time. Systems and their information security risk are dynamic, subject to changes to system components and operating environments as well as internal or external changes in the threats and vulnerabilities those systems face. Step 6 of the Risk Management Framework emphasizes the importance of implementing a consistent, structured approach for identifying, managing, documenting, and responding to changes that may impact the security of operational information systems. Continuous monitoring supports this process by identifying changes to systems and their operating environments and providing information that can be used in ongoing security control assessments.
Agencies implement formal configuration management and control processes to manage the process of making necessary changes to systems and their environments, using continuous monitoring to help identify internally or externally driven factors that require such changes. Configuration management establishes baseline system configuration information using details provided in system design documentation, technology specifications, system security plans, operational procedure manuals, and other sources. System owners or their operations teams should provide detailed information about system components identified as configuration items, including hardware specifications, software versions, configuration settings, and security control implementation descriptions [25]. Along with similar details about the environment in which the system operates, this information provides the basis for considering planned or unanticipated changes and assessing the potential security impact of those changes. Ideally, organizations do not make changes to information systems without assessing the security impact in advance but not all changes are intentional or planned, so the automated tools increasingly used by agencies to support continuous monitoring provide an important means of detecting and reporting on and system changes.
Agencies conduct security impact analyses to determine the extent to which planned or already-occurred changes to the information system or its operating environment affect the security posture of the system or the risk is operation poses to the organization. The range of possible changes affecting an information system include how controls are implementation or configured, new threats or vulnerabilities that existing controls may not adequately address, and new legal, regulatory, or policy requirements that correspond to a need to implement new security controls or control enhancements. Security impact analysis identifies factors affecting system security that require corrective action, potentially necessitating the creation of new items in the plan of action and milestones and updates to the system security plan as well as the need to assess modified or newly implemented controls [26].
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597496414000096
Security for Distributed Systems: Foundations of Access Control
Elisa Bertino, Jason Crampton, in Information Assurance, 2008
Access Control Lists and Multiple Principals
A number of different options exist for authorization systems based on access control lists when a subject may be associated with a number of different principals. Some systems only permit each object to be associated with a fixed number of subjects. In other words, each object has a fixed-length access control list. Unix is an example of such a system, in which each object has an access control list with three entries: one for the object owner, one for the group associated with the object, and one for every other user (sometimes referred to as “the world”). Windows 2000, in contrast, permits access control lists of arbitrary length.
We can also decide whether the authorizations of a subject are represented by the most relevant principal or by the aggregation of the authorizations for each principal associated with that subject. Unix chooses the first option: If the subject is the owner of the requested resource, only the authorizations of the owner principal are considered when deciding whether to allow the request. If the subject is not the owner but belongs to the group, then only the authorizations of the group principal are considered. If the subject is neither the owner nor belongs to the group, then the authorizations of the world principal are considered. This means that an owner could have less access than a member of the group, although the owner can always change the access control list so that he or she has all access rights. In contrast, Windows will check every entry in an access control list in deciding whether an access request should be granted.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780123735669500057
System Security Plan
Stephen D. Gantz, Daniel R. Philpott, in FISMA and the Risk Management Framework, 2013
Ongoing Maintenance Plan
The system security plan supports both initial system authorization and ongoing operation and security management activities for the system once deployed into production. The completed system security plan describes the process by which the security plan itself will be assessed and updated as necessary, including the schedule for routine periodic reviews and events or circumstances that would trigger review and might result in changes to the SSP. NIST guidance, consistent with provisions in FISMA, directs system owners to review and update their system security plans at least annually [53]. Special Publication 800-18 lists a series of potential changes to systems or their management and oversight that should prompt review of the SSP, including changes in information system owner, information security officer, or authorizing official; changes in system architecture or system interconnections; and changes in system scope, operating status, or certification and accreditation status [17].
The ongoing maintenance description in the system security plan should also reference the continuous monitoring strategy developed for the system, or organizational unit, environment, or agency continuous monitoring strategies if a broader scope approach is used instead of a system-specific strategy. The monitoring strategy can be included in the system security plan, inherited and incorporated by reference from a general support system or other common control provider, or developed and documented separately from the SSP. Current NIST guidance to agencies on continuous monitoring [57] provides much more explicit direction to agencies than what is included in Special Publication 800-37 on the process to be followed and content to be included in information security continuous monitoring strategies, and Special Publication 800-18 does not explicitly reference continuous monitoring at all. The monitoring strategy task in the RMF emphasizes ongoing monitoring of system-specific security controls [17], but agencies increasingly specify monitoring requirements in organization-wide policies and procedures. Special Publication 800-137 directs agencies to define continuous monitoring strategies and implement monitoring programs at an organization-wide scope that also address mission and business and system-specific monitoring practices and procedures [57]. With the increased attention focused on continuous monitoring activities and the broad perspective continuous monitoring strategies must reflect, system owners are generally less likely to develop their own system-specific approaches. Even where system-specific continuous monitoring strategies are needed, such strategies will need to reference and incorporate agency-wide strategies and risk management information typically beyond the scope of the SSP. For these reasons, agencies and their system owners should find it more practical and efficient to develop continuous monitoring documentation separate from system security plans, and provide references to continuous monitoring strategies and procedures from the SSP.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597496414000102
Risk Management
Stephen D. Gantz, Daniel R. Philpott, in FISMA and the Risk Management Framework, 2013
Information System Risk Assessments
Enterprise risk management relies on effective risk assessments. With the number and diversity of threats organizations face, risk managers need to use thorough, consistent methods to evaluate known and emerging threats and vulnerabilities, to consider the impact of changes affecting information systems and their operating environments, and to provide information to guide decisions about appropriate risk responses. Risk assessment is a core function supporting a variety of security management processes, including system certification and accreditation, incident response, contingency planning, and continuous monitoring. In addition to supporting information security management, risk assessments also provide inputs to other information resources management activities such as IT strategic planning, capital planning and investment control, enterprise architecture, program management, and execution of system development life cycle phases. NIST considers risk assessment significant enough to warrant specialized guidance on conducting risk assessments for information systems, mission functions and business processes, and organizations [8]. The expansion in scope for Special Publication 800-30 Revision 1 to apply risk assessment processes to all tiers of the organization reflects a similar shift in focus from information system-specific guidance to enterprise guidance seen in other updated NIST Special Publications [56].
Risk assessment is most often associated with initial system authorization activities or required periodic (usually annual) assessments of operational systems. Organizations can, however, apply the same fundamental risk assessment process at different levels of granularity and with broad or narrow scope. Organizations conduct risk assessments in three primary contexts:
1.Comprehensive assessments performed to implement the Assess step in the risk management process, whether at the information system, mission and business process, or organization level.
2.Focused assessments of specific threats, vulnerabilities, or weaknesses identified during security control assessments or continuous monitoring activities.
3.E-authentication risk assessments required under OMB regulations for information systems providing remote authentication of users.
Organizations need to assess risk on an ongoing basis and whenever new threats or vulnerabilities arise or circumstances change that could impact overall risk levels or otherwise warrant a response. The nature and points of emphasis for information system risk assessments vary depending on which phase in the system development life cycle the system is in and on the types of risk factors that need to be assessed. The results of risk assessments are typically documented in risk assessment reports or incorporated in other security management artifacts such as security assessment reports. As shown in Figure 13.4, risk assessment results provide key information to multiple steps in the Risk Management Framework. Initial risk assessment activities often precede initiation of the RMF and supply key information to system categorization and security control selection. NIST provides guidance to agencies in Special Publication 800-30 Revision 1 applicable to conducting risk assessments of any size or scope. In addition to Special Publication 800-30, primary sources of guidance for conducting e-authentication risk assessments include OMB Memoranda M-04-04 [57] and M-00-10 [58], Special Publication 800-63 [59], and the e-authentication e-RA tool and associated guidance for agencies available from the federal Identity, Credential, and Access Management (ICAM) Subcommittee [60].
Figure 13.4. Information System Risk Assessments Follow an Iterative Development Approach Initiated Before the Beginning of the RMF Process, Informed by Security Control Assessment Results and Other Outputs of RMF Activities, and Updated in Support of Initial and Ongoing System Authorization
Risk Models
There are many risk assessment tools and techniques available for use in analyzing risk components and making risk determinations. Risk modeling is one approach recommended in Special Publication 800-30 to identify all the elements necessary to perform risk analysis for different types of threats. Risk models specify the factors needed to assess risk and the relationship among those factors, producing a sort of template for risk assessors to use in their assessments. By defining required risk elements in a standard way, risk models help ensure that risk assessors consider all relevant factors, encourage consistent assessment procedures for different types of risk, and highlight potential information gaps that may hamper efforts to make accurate risk determinations. Figures 13.5 and 13.6 provide sample risk models for adversarial and environmental threats, respectively, that identify the set of risk factors that should be included in risk assessments. As these two examples illustrate, different attributes apply to different types of risk—for example, consideration of intent and organizational targeting in the adversary-based model is irrelevant for environmental threats such as natural disasters. When risk assessors can fully populate a risk model for a specific threat with information to address all the factors in the model, the complete model instance provide a risk scenario that can be used to describe in detail the way a threat might materialize and how it would affect the organization.
Figure 13.5. A Risk Model for Adversarial Threats Includes Related Information About Vulnerabilities, Likelihood, and Impact That Collectively Help Determine the Risk Posed By Each Threat [61]
Figure 13.6. A Risk Model for Environmental Threats Includes the Same Core Related Factors Such As Vulnerabilities, Likelihood, and Impact, But Omits Factors Related to Threat Source Motivation Or Skills That Would Be Relevant for Adversarial Or Accidental Types of Threats
Assessment Methods
Despite the number and variety of risk assessment methods, approaches to risk assessment typically belong to one of three categories: quantitative, qualitative, or hybrid [62]. Quantitative risk assessment incorporates numeric values produced via direct measurement or observation or obtained through empirical evidence to enable use of mathematical and statistical analysis methods. Quantitative assessments express asset valuation and impact in dollars, time, or other continuous values, and use probability calculations or estimates to determine likelihood. Where objective, accurate measures are available, quantitative risk assessments produce risk determinations easily compared to each other and well suited to cost-benefit analysis. Quantitative assessments facilitate risk ranking and prioritization activities, but their validity depends on the ability of risk assessors to accurately determine values used in risk calculations. The emphasis on numeric scoring can give the impression of clear differences among risk ratings where no significant differences actually exist.
Qualitative assessments measure risk factors using categorical or ordinal ratings, often relying on the knowledge and expertise of risk assessors to correctly apply subjective and relative values. NIST information security standards and guidelines often use qualitative assessment scales, such as the low/moderate/high ratings used in security categorization. Qualitative analysis can be easier to apply than quantitative alternatives, particularly in public sector contexts where operational performance is not often measured in quantitative terms such as revenue or profit. Challenges associated with qualitative assessments include the inherent subjectivity associated with assigning ratings to risk factors and the difficulty in making meaningful differentiations and prioritizing among risk determinations with similar assigned values.
Hybrid assessment methods—often called “semi-quantitative” or “pseudo-quantitative”—add numerical scales to ordinal rating levels to support statistical analysis and facilitate better differentiation among assessed values and risk determinations than in purely qualitative approaches. The guidance on conducting risk assessments in Special Publication 800-30 Revision 1 uses this type of approach, defining five ordinal rating values (very low, low, moderate, high, and very high) for assessing threat sources, vulnerabilities, likelihood, impact, and risk, and assigning numeric rating scales to each value (0–4, 5–20, 21–79, 80–95, and 96–100, respectively) [63].
Warning
The use of numeric rating scales with qualitative assessment values does not change the subjectivity inherent in the rating process. Organizations hoping to improve their ability to compare and rank risk using semi-qualitative ratings must provide clear guidance and rating criteria to risk assessors to ensure that assessment ratings are used consistently.
Analysis Approaches
Regardless of the risk assessment method selected, different organizations may apply different analytical approaches when conducting their assessments. NIST distinguishes approaches by the primary elements on which the analysis focuses, the level of detail and rigor required in the analysis, and the extent to which standard or common risk models are used across the organization to analyze similar threats. The NIST risk assessment process is equally well suited to threat-oriented, vulnerability-oriented, or asset-oriented analysis approaches [64]. Current federal guidance recognizes a variety of possible risk assessment triggers, including new threats or vulnerabilities identified through continuous monitoring, weaknesses identified in security control assessments, and changes to information systems, operating environments, or organizational mission and business priorities. When developing the risk management strategy during risk framing, organizations can identify or recommend specific analytical approaches for use in different risk assessment contexts as well as approved assessment methodologies, striking an appropriate balance between mandated standards that ensure consistency and the flexibility to apply the most effective approaches to different risk assessment needs.
As part of the changes in guidance proposed in Revision 1 to Special Publication 800-30, NIST adopted a structured process defining major assessment steps and tasks performed within each step, mirroring the description of the Risk Management Framework in Special Publication 800-37. Although NIST guidance presumes the use of its risk assessment approach, federal agencies are free to employ other risk assessment methodologies if they wish, and many alternatives to Special Publication 800-30 are available [65]. For consistency with the material presented throughout this book, this chapter describes the NIST process, illustrated in Figure 13.7, which includes preparation and maintenance activities, but emphasizes a sequenced set of tasks for consistently conducting risk assessments.
Figure 13.7. NIST Guidance for Conducting Risk Assessments Prescribes a Structured Sequence of Tasks That Helps Risk Managers Identify and Evaluate Sources of Risk and Make Consistent Determinations of Risk to Information Systems, Mission Functions and Business Processes, and Organizations [66]
Prepare
The preparation step establishes the scope and parameters of the risk assessment to be performed. Given the potential volume of information required, resources involved, and methods that may be applied, successful completion of the assessment may depend on effective preparation. Risk assessment context may be derived from organizational risk management strategy, with assessment-specific tailoring as needed depending on the level at which the assessment will be conducted and the objectives it is intended to achieve. Risk assessment preparation includes identifying the purpose and scope of the assessment; identifying assumptions and constraints; identifying information requirements and sources; and developing, selecting, or refining the risk model [67]. The risk management strategy may be instrumental in facilitating the completion of these tasks, complemented by information in continuous monitoring strategies, system security plans, and risk assessment policies, procedures, guidelines, and templates.
Risk assessment preparation also includes determining the level of the organization at which risk assessments should be conducted, often depending on the nature and scope of the threat or vulnerability that serves as the catalyst for the assessment. In cases where a threat or vulnerability is identified for a particular information system, organizations should consider whether the risk factor’s applicability is limited to that system or applies more broadly to other systems or business processes, or organization-wide. For example, a web application vulnerability found in one information system might also be present in others, and a threat event such as a denial of service attack is likely to threaten any systems sharing the same operating environment or network infrastructure. Some threats are by nature applicable to entire organizations—such as the sort of sophisticated, organized, and ongoing attacks that characterize the advanced persistent threat—and corresponding risk from these threats should be assessed at the organizational level.
Conduct
As explained previously in the description of the Assess component in the risk management process, conducting a risk assessment involves identifying and characterizing the threats and vulnerabilities relevant to the subject of the assessment (such as an information system, business process, or entire organization), estimating the likelihood that threat events will occur and the resulting adverse impact to the organization, and making a risk determination as a function of likelihood and expected impact. NIST guidance organizes its risk assessment tasks in an ordered sequence, as seen in the center of Figure 13.7, but acknowledges that completing the tasks in a different order or choosing to iterate some tasks multiple times before moving to subsequent tasks may be necessary and appropriate [68]. Special Publication 800-30 offers risk assessors extensive supplemental information on threat sources, threat events, vulnerabilities and predisposing conditions that may be relevant to government agencies. The risk factors NIST presents are not intended to be exhaustive or prescriptive, but can provide a foundation for considering and categorizing different types of risk in different organizations and help risk assessors avoid examining too narrow a set of risk inputs. Special Publication 800-30 also provides five-level rating scales and rating level descriptions for likelihood, impact, and risk determinations, which organizations can adapt to their own risk management strategies.
Maintain
Comprehensive risk assessments, like security control assessments, are relatively large-scale efforts requiring significant time and resources to complete. Many organizations conduct risk assessments on an annual basis or at other infrequent intervals, although the current government emphasis on continuous monitoring (including risk monitoring) may encourage a shift to more frequent, smaller-scale assessments. Regardless of scope, risk assessments should reflect current risk to the organization, and therefore need to be maintained and updated to ensure the information produced from risk assessments is relevant, accurate, and up to date. Maintaining a risk assessment requires risk monitoring to identify changes in risk factors or overall risk addressed in the assessment, and revising and updating assessment information, including reassessment of risk elements where necessary. This aspect of the risk assessment process leverages the risk monitoring strategy and capabilities implemented at organizational, mission and business process, and information system levels. Key risk assessment maintenance activities include documenting the risk factors to be monitored and the monitoring frequency; validating the contextual details of the assessment such as purpose, scope, assumptions, and constraints; performing appropriate risk assessment tasks; and updating risk assessment results and communicating those results to risk managers or other stakeholders [69].
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597496414000138
Securing Web Applications, Services, and Servers
Gerald Beuchelt, in Computer and Information Security Handbook (Third Edition), 2017
Building Federations With WS-Federation
Since WS-Trust is only used for building a distributed authorization system, OASIS has created a number of other protocols for the WS-∗ stack focusing on different functionalities. One of these is the WS-Federation specification which is used to enable the leveraging of security tokens issued by STS form different administrative domains. This means that a client can obtain a token from “their” STS, and use this to access relying parties that usually trust only tokens issued by another STS. The prerequisite for this to work is setting up a federation.
It should be noted that the most significant amount of work for creating a federation is typically not the technical configuration: creating and maintaining the necessary business agreement between two organizations is complex and requires collaboration with legal, finance, and potentially human resources subject matter experts.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780128038437000107
Security Assessment Report
Stephen D. Gantz, Daniel R. Philpott, in FISMA and the Risk Management Framework, 2013
Summary
The security assessment report presents the findings from security control assessments conducted as part of the initial system authorization process for newly deployed systems or for periodic assessment of operational systems as required under FISMA. In addition to assessment results and recommendations to address any system weaknesses or deficiencies identified during security control assessments, the security assessment report describes the purpose and scope of the assessment and procedures employed by assessors to arrive at their determinations. The results provided in the security assessment report, in conjunction with the system security plan and plan of assessment and milestones, enable authorizing officials to thoroughly evaluate the effectiveness of security controls implemented for an information system, and to make informed decisions about whether an information system should be authorized to operate. This chapter described the process of producing a security assessment report, and explained many aspects of planning and conducting security control assessments that influence the contents and usability of the report. This chapter also summarized key information about security control assessments contained in federal guidance available to system owners and security assessors, and highlighted the ways in which security assessment reports are affected by and used to support other activities in the system authorization process described in NIST’s Risk Management Framework.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597496414000114
Federal Information Security Fundamentals
Stephen D. Gantz, Daniel R. Philpott, in FISMA and the Risk Management Framework, 2013
Certification and Accreditation Process
Appendix III of OMB Circular A-130 requires agencies to authorize processing for federal information systems, including general support systems and major applications. System authorization—accomplished through the use of certification and accreditation process—is a formal, written approval that adequate security protection exists for a system before it becomes operational. Not every system is subject to individual certification and accreditation—OMB defines major applications as those requiring “special attention to security due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application” [38]. Systems not meeting this standard still require some level of protection, but agencies often incorporate non-major applications within the scope of security protection provided by the general support system in which those applications reside. Agencies certifying and accrediting information systems in the civilian, defense, and intelligence sectors follow different processes, each described in more detail in the Certification and Accreditation section later in this chapter. The core tasks and activities in all of these processes are quite similar, and the different sectors are moving towards a common government-wide methodology through the efforts of the Joint Task Force Transformation Initiative. Based on applicable policies and agencies guidance current as of 2012, civilian agencies follow the certification and accreditation process embedded in the NIST Risk Management Framework, [39] defense agencies follow the DoD Information Assurance Certification and Accreditation Process (DIACAP), [40] and intelligence agencies and others operating national security systems are migrating from the National Information Assurance Certification and Accreditation Process (NIACAP) [41] to the RMF.
Warning
The terms certification and accreditation are widely used in both public sector and commercial information security management, but their meaning differs between government and non-government contexts, and even varies within government usage. In federal information system certification and accreditation process, including the RMF, DIACAP, and NIACAP, certification refers to the evaluation and affirmation of the extent to which the security controls implemented for a system meet the system’s security requirements, in support of an accreditation decision. Accreditation is the formal decision by an authorizing official that a system’s implemented security controls and residual risk are acceptable to the organization and that the system is approved to be put into operation. Beyond the scope of authorizing processing for information systems, certification typically indicates compliance, such as with a specific standard or set of requirements, while accreditation refers to the endorsement of an organization as minimally competent to perform a particular function or serve in a particular capacity. For instance, many organizations seek ISO certification to demonstrate conformance with various standards, including those related to information security such as ISO 27001. Such certifications are granted by accredited registrars or other organizations explicitly approved to serve as certification bodies. Both connotations apply to NIST, whose FISMA Implementation Program issues guidance for conducting certification and accreditation of federal information systems, and whose National Voluntary Laboratory Accreditation Program evaluates and approves many types of laboratories as qualified to certify different products for conformance to applicable standards. It is important to clearly specify the context when referring to certification and accreditation activities to avoid potential confusion when using these terms.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597496414000023
Continuous Monitoring
Stephen D. Gantz, Daniel R. Philpott, in FISMA and the Risk Management Framework, 2013
Integrating Continuous Monitoring with Security Management
Continuous monitoring represents an important operational security capability on its own, but it is also an essential contributing function to ongoing information system security management. Continuous monitoring supports key RMF tasks conducted after system authorization, including ongoing risk assessment, updates to security plans and other documentation, and security status reporting. System owners and authorizing officials consider information provided through ISCM activities to determine necessary changes in implemented system-specific and common controls and to inform risk management practices and decisions. As ongoing security control assessments and continuous monitoring activities proceed, security assessment reports should be updated to reflect assessment findings produced by assessors and any changes to security controls need to be updated in system security plans of systems implementing those controls. Updates to plans of action and milestones occur as needed as corrective actions are completed or as new actions and milestones are added to address vulnerabilities discovered during monitoring or control assessments. System owners, authorizing officials, and others with responsibility for organizational security management and oversight receive status reports that include the results of ISCM activities. Security control monitoring, as an integral part of the operations and maintenance phase of the system development life cycle, continues throughout the operational life of the system [22].
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B978159749641400014X
Biometric Authentication for SCADA Security
Jack Wiles, in Techno Security's Guide to Securing SCADA, 2008
Identify Your System Priorities Before Choosing a Biometric Application
Choosing a biometric reader should be a function of your company's priorities and the reader's function in the SCADA system. Is your company's most significant priority convenience of the biometric capture when a person requests system authorization? Many companies are concerned that the capture of biometric samples will slow access to vital facilities for repair and control functions; they therefore wish to find a system that, once implemented, can quickly and simply pass people through to their authorized destination.
You can imagine that, noting an emergency in the water treatment facility, company management would not want its authorized employees to waste time in accessing the facilities that need immediate repair or analysis. In this case, any biometric reading that forces its subjects to hold still for several seconds would be problematic. Retinal capture is clearly not the best solution.
In this instance, it may be best for your company to capture the biometric reading from a distance. If so, then fingerprints or iris scans would be impossible and you should consider voice recognition or facial geometry software. The biometric sample comparison settings in this type of situation would probably allow significant variation between the original sample and the access sample, so that the system unlikely would render false negative readings.
Conversely, your company's priorities may run toward the highest level of security possible for access to controls in a nuclear facility, leading your company to choose a biometric authentication process that minimizes the possibility of false positive readings. Your business would therefore select a system and sample readers that are least likely to be fooled by a terrorist attempting entry to the secure facility, and you would be willing to trade speed of access for certainty of authorization. In this case, a retinal scanning system may be the best match for access control, while distance face readers would not be.
Always remember that the biometric authentication is used as part of a larger, more complex system. If your company plans to implement an intense security regime, it could always measure different sets of biometrics at different locations. For example, they could use voice recognition to enter the facility, while requiring retinal scans at the door to the control room or fingerprint readers to access the control computers.
Of course, your company's priorities in choosing biometric measurements may be driven by entirely administrative concerns, such as cost, available equipment, ease of implementation, the need for simplicity, or problematic environmental issues. No company can brag of limitless resources.
While many organizations aspire to implement the best possible security solutions, they may have the resources only for the lower-cost solutions. In addition, an enterprise looking to purchase a biometric authorization function for its SCADA security regime can choose only from the solutions available at the time from reputable vendors. Creating new hardware and software is likely to be economically impossible, therefore restricting choices to those available within a company's price range.
Often, tried and true methods like fingerprint analysis may be the best solution. They can provide a high level of security while using equipment that has been tested in other environments.
Biometric technology is often viewed as a cutting edge solution, and people who ride the cutting edge are frequently hurt. They may suffer because the technology is untested and does not work as well as everyone had hoped. They may suffer because the technology is overly complex and does not integrate well into a SCADA security system. They may suffer because the technology is not easy to use and the company employees are constantly denied the access they need. The most valuable and practical decision may involve choosing a system that can demonstrate years of predictable behavior and that is understood by all participants.
The company must also consider where and how the biometric readers will be used in the overall security system. Important considerations for allowing access to SCADA security facility and systems can include how the biometric components work within the system. Where are the readers placed and how are they monitored? Will the person seeking access be likely to be carrying papers or tools and therefore not be able to offer free hands to the system? Then an eye or ear scanner or voice recognition system may be the best choice.
If the reader is installed in an outdoor environment, how will the equipment and the test subject be affected by the weather? An oil industry technician seeking access to a pipeline facility north of the Artic Circle should not be expected to remove his gloves and expose his hands when the temperature may be 50 degrees below zero. A power company technician attempting to reach a switching station during a hurricane should not be expected to hold still long enough for retinal scanners to confirm his identity.
Voices can be muffled and overridden in busy sites or by high winds on the open plains. The human element is not the only vulnerable variable when reading biometric signs outdoors. Biometric readers placed outside and exposed to the elements cannot be expected to continually function unaffected by their environment, whether those elements are excessive heat, cold, moisture, or corrosion.
When selecting the type of biometric measurement that your company will capture, all of the company's priorities must be considered and weighed against the administrative realities of the SCADA system that your company is protecting and the budget that is available to spend. However, whether you decide to measure eyes, ears, faces, hands, or voices, the decision should match the objectives of your security system. Map your companies SCADA security priorities to the strengths and weaknesses of the many biometric capture options. Biometric security capture devices offer several choices to match the human authentication needs of any SCADA infrastructure.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597492829000087