Publications

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

This document is a draft SecuritybyDesign (SeBD) handbook produced to support the Work Plan of the Nuclear Security Summit to share best practices for nuclear security in new facility design. The Work Plan calls on States to %E2%80%9Cencourage nuclear operators and architect/engineering firms to take into account and incorporate, where appropriate, effective measures of physical protection and security culture into the planning, construction, and operation of civilian nuclear facilities and provide technical assistance, upon request, to other States in doing so.%E2%80%9D The materials for this document were generated primarily as part of a bilateral project to produce a SeBD handbook as a collaboration between the Japan Atomic Energy Agency (JAEA) Nuclear Nonproliferation Science and Technology Center and Sandia National Laboratories (SNL), which represented the US Department Energy (DOE) National Nuclear Security Administration (NNSA) under a Project Action Sheet PASPP04. Input was also derived based on tours of the Savannah River Site (SRS) and Japan Nuclear Fuel Limited (JNFL) Rokkasho Mixed Oxide Fuel fabrication facilities and associated project lessonslearned. For the purposes of the handbook, SeBD will be described as the systemlevel incorporation of the physical protection system (PPS) into a new nuclear power plant or nuclear facility resulting in a PPS design that minimizes the risk of malicious acts leading to nuclear material theft; nuclear material sabotage; and facility sabotage as much as possible through features inherent in (or intrinsic to) the design of the facility. A fourelement strategy is presented to achieve a robust, durable, and responsive security system.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Decision Trees, algorithms, software code, risk management, reports, plans, drawings, change control, presentations, and analysis - all useful tools and efforts but time consuming, resource intensive, and potentially costly for projects that have absolute schedule and budget constraints. What are necessary and prudent efforts when a customer calls with a major security problem that needs to be fixed with a proven, off-the-approval-list, multi-layered integrated system with high visibility and limited funding and expires at the end of the Fiscal Year? Whether driven by budget cycles, safety, or by management decree, many such projects begin with generic scopes and funding allocated based on a rapid management 'guestimate.' Then a Project Manager (PM) is assigned a project with a predefined and potentially limited scope, compressed schedule, and potentially insufficient funding. The PM is tasked to rapidly and cost effectively coordinate a requirements-based design, implementation, test, and turnover of a fully operational system to the customer, all while the customer is operating and maintaining an existing security system. Many project management manuals call this an impossible project that should not be attempted. However, security is serious business and the reality is that rapid deployment of proven systems via an 'Extreme Project' is sometimes necessary. Extreme Projects can be wildly successful but require a dedicated team of security professionals lead by an experienced project manager using a highly-tailored and agile project management process with management support at all levels, all combined with significant interface with the customer. This paper does not advocate such projects or condone eliminating the valuable analysis and project management techniques. Indeed, having worked on a well-planned project provides the basis for experienced team members to complete Extreme Projects. This paper does, however, provide insight into what it takes for projects to be successfully implemented and accepted when completed under extreme conditions.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Abstract not provided.

Decision Trees, algorithms, software code, risk management, reports, plans, drawings, change control, presentations, and analysis - all useful tools and efforts but time consuming, resource intensive, and potentially costly for projects that have absolute schedule and budget constraints. What are necessary and prudent efforts when a customer calls with a major security problem that needs to be fixed with a proven, off-the-approval-list, multi-layered integrated system with high visibility and limited funding and expires at the end of the Fiscal Year? Whether driven by budget cycles, safety, or by management decree, many such projects begin with generic scopes and funding allocated based on a rapid management 'guestimate.' Then a Project Manager (PM) is assigned a project with a predefined and potentially limited scope, compressed schedule, and potentially insufficient funding. The PM is tasked to rapidly and cost effectively coordinate a requirements-based design, implementation, test, and turnover of a fully operational system to the customer, all while the customer is operating and maintaining an existing security system. Many project management manuals call this an impossible project that should not be attempted. However, security is serious business and the reality is that rapid deployment of proven systems via an 'Extreme Project' is sometimes necessary. Extreme Projects can be wildly successful but require a dedicated team of security professionals lead by an experienced project manager using a highly-tailored and agile project management process with management support at all levels, all combined with significant interface with the customer. This paper does not advocate such projects or condone eliminating the valuable analysis and project management techniques. Indeed, having worked on a well-planned project provides the basis for experienced team members to complete Extreme Projects. This paper does, however, provide insight into what it takes for projects to be successfully implemented and accepted when completed under extreme conditions.

Abstract not provided.

Abstract not provided.

Assigning an acceptable level of power reliability in a security system environment requires a methodical approach to design when considering the alternatives tied to the reliability and life of the system. The downtime for a piece of equipment, be it for failure, routine maintenance, replacement, or refurbishment or connection of new equipment is a major factor in determining the reliability of the overall system. In addition to these factors is the condition where the system is static or dynamic in its growth. Most highly reliable security power source systems are supplied by utility power with uninterruptable power source (UPS) and generator backup. The combination of UPS and generator backup with a reliable utility typically provides full compliance to security requirements. In the energy market and from government agencies, there is growing pressure to utilize alternative sources of energy other than fossil fuel to increase the number of local generating systems to reduce dependence on remote generating stations and cut down on carbon effects to the environment. There are also conditions where a security system may be limited on functionality due to lack of utility power in remote locations. One alternative energy source is a renewable energy hybrid system including a photovoltaic or solar system with battery bank and backup generator set. This is a viable source of energy in the residential and commercial markets where energy management schemes can be incorporated and systems are monitored and maintained regularly. But, the reliability of this source could be considered diminished when considering the security system environment where stringent uptime requirements are required.

Abstract not provided.