Developing Functional Requirements for Physical Security Projects

This article on creating functional requirements for physical security projects was adapted from a previous webcast presented by Mark Schreiber from Safeguards Consulting. Mr. Schreiber has more than 20 years of experience in Security Engineering and is a Certified Protection Professional through ASIS international.

Table of Contents:

Introduction

Physical security systems are essential to protecting personnel and critical assets. But before construction or implementation can begin, there must be functional security requirements for physical security projects. This requires significant planning, budget allocation, and collaboration between different stakeholders within an organization.

The process can seem intimidating for security professionals who may have never taken part in such an initiative. Fortunately, there are proven methodologies that can be applied to advance these complex security projects systematically and efficiently. This article addresses comprehensive projects, such as multilocation renovations and implementing campus-wide security systems. The purpose is to provide an overview of what to expect when you undertake these large-scale projects.

 

Begin with Regulatory and Liability Considerations

Key takeaways:

  • Federal and state regulations are part of the minimum standards for any security project.
  • Liability concerns are also part of the minimum standards.
  • Your legal team can help you understand these regulatory and liability considerations.

When considering or planning security improvements, it’s important to start with a high-level view of objectives and desired outcomes before diving into the details. The beginning of the process is understanding what is required from a safety and security standpoint, what fits the business model, and how that can be implemented.

So whether you have federal or state regulatory requirements – which could be everything from safety standards to more stringent DHS or DOD-type requirements – those should be part of your minimum standards and your starting point for any security project. Complying with these regulations is simply part of the cost of doing business, the cost of supporting security within your environment.

Every organization also has liability concerns, which will be best understood by your legal department. Your legal team can help you understand how you can support duty of care, premise liability, other legal issues or precedents, as well as foreseeability in protecting your organization. These liability considerations are also part of the minimum standard you should address with security projects or investments.

Security Program Lifecycle and Continuous Improvement

Key takeaways:

  • Budgetary limitations often prevent all desirable physical security projects from being implemented at once.
  • Security programs are best viewed as a continuous lifecycle that includes operation, analysis, planning, design, and implementation.
  • Organizations should strive for continual improvement rather than ‘one and done.’

Because liability and regulatory concerns must be addressed, and budgets are limited, it is common for organizations to implement security projects and programs that adequately address these minimums – and then begin to operate.

But if you fixate on an operations-only mindset, you may stagnate and fall behind. You may fail to identify potential risk. You may even accidentally introduce risk and liability. It is usually much more effective to expand your approach beyond an operational focus and look at implementing things such as continuous improvement. This will enable you to support your operations as you seek opportunities to continually improve.

Security Program Lifecycle diagram

That’s when you bring in an analysis phase, a planning phase, design phase and implementation phase that feeds right into our standard security operations. And you continue circling through that process, whether that’s done on a quarterly basis, annual basis, or whatever is appropriate for the organization and its staff and resources.

Everyone can benefit from having this kind of continuous improvement mindset when thinking about security improvements. The analysis component is likely to reveal more risks than you are able to address at once. You will probably need to prioritize the risks you wish to address first and focus on early wins by demonstrating they have been adequately addressed. This can also help to show return on investment early in the process and reduce budget objections down the road.  Later you can return to address other risks

The Role of Security Risk Assessments

Key takeaways:

  • Risk assessments allow you to define which threats, vulnerabilities, and assets should have the highest priority.
  • Regardless of your organization, you can use a standardized and repeatable risk assessment methodology.
  • Focus first on adequately mitigating the highest priority risks before moving on to address other risks.

Security risk assessments are the most common industry standard for supporting this continual improvement within physical security and security operations overall. “Risk assessment” is a term that shouldn’t scare anybody because the objective is risk mitigation.

Every mature security organization should conduct risk assessments on a regular basis, but how they are handled varies greatly between organizations. Regardless of your organizational characteristics, there is a standardized process and multiple distinct methodologies that you can implement to support risk assessments. Here is a sample risk assessment template from the U.S. Department of Agriculture.

At the macro level the risk identification process allows you to define which threats, vulnerabilities, and assets have the highest priority for your security risk mitigation. This allows you to allocate available resources to those highest priority risks, and then deal with the other risks as appropriate. Note that risks may ultimately be addressed with physical security measures, employee training, expanded insurance coverage, and other methods.

Risk assessments are used to provide a holistic, all-hazards view of all your security organization’s requirements. And this should be tied directly into your enterprise risk approach. This is true if your organization takes an enterprise risk management approach and you tie in security risk to that, or if your organization specifically uses an enterprise security risk management perspective, in which security comprehensively supports all departments within the organization.

As you mature and you go through the risk assessment process methodology over time, you will knock off the higher risks before you address the medium risks, and then eventually the low-risk items in a very strategic and methodical approach.

Regardless of the approach you take, the more you can identify risks and appropriately prioritize and address those risks, the more likely you’ll be able to mature your security operation

Applying Commercial and Industrial Security Principles

Key takeaways:

  • After identifying and prioritizing risks with a risk assessment, it’s time to apply industrial security principles to identify the appropriate measures.
  • Consider potential measures from the perspective of the 5 D’s and layered defenses.
  • Consider confidentiality, integrity, and availability whenever any security measure involves critical or sensitive data.

Once you have a good understanding of how you are assessing and prioritizing your risks, then you can start to apply standard security principles. These are universal, and widely used for decades. The key is understanding how to handle these principles in a formal methodology.

You have the 5 D’s of Deter, Deny, Detect, Delay and Defend (or Destroy in the military version). Those different methodologies give us options for security measures.

You then apply defense in depth, where you’re trying to provide a layered security approach. You want to have multiple security measures rather than just one single dependent solution. That way, a single vector or penetration is more likely to be prevented from impacting critical assets. You want to create a level of redundancy as we’re trying to address these security concerns.

The next principle we apply is Confidentiality, Integrity, and Availability (CIA). This concept is relatively new to physical security, and it comes from our cybersecurity colleagues. Without delving too deeply, it’s very important to understand that you’re not only managing and protecting physical assets and people. You are also managing critical data that must be protected while remaining accessible to the organization. So you examine how you can keep that data confidential, make sure that the data itself is authentic, and ensure it’s available for business functioning without being compromised. CIA is now fundamental for security operations.

And last but not least is continuous security, which means you add layers on consistent basis as much as possible. You want to complete each layer of security before adding another layer (and with it more complexity). Adversaries and threat actors will seek to exploit the weakest link. And so you want to protect your assets in an equal manner across the organization as appropriate based on the risk.

Creating Functional Requirements for Physical Security Projects

Key takeaways:

  • Functional requirements for physical security projects connect an improvement to a specific risk we wish to mitigate.
  • Create functional requirements that are simple, concise and vendor-agnostic.
  • Whenever possible, create functional requirements that are universally applicable to your organization.

Once you have this good understanding of how you’re going to define and treat your very specific high risks, it’s important to understand and communicate what should the improvement be. Functional requirements are the industry standard for how you communicate the needed improvements. Functional requirements for physical security projects address how you’re going to improve our organization’s security posture by connecting an improvement to a specific risk you wish to mitigate.

Functional requirements themselves should be simple and concise. They should not get into the weeds or use complex concepts or language. You want them to be simple, so they are as portable and universal across the organization as possible. They should not be specific to technologies. Why? You may define a functional requirement today, and the technology environment could change drastically over the next six months or two years – before you get a chance to implement it. A specific technology or brand may change drastically within that timeframe. Regardless of potential technology changes, you still want to meet that core security need.

Finally, these functional requirements should be universal to your organization, regardless of the campus, facility, site, or country you’re applying these to. You want them to be universal to your organization to not only create a standard, but ensure you are consistently addressing risk across the organization. Of course, you can still address local variances that may require additional hardening or protective measures.

These functional requirements independently become part of your security program as components of your project design and as measurable activities that you will later analyze as part of the continuous improvement cycle.

Some of functional requirements are personnel focused. Some of them deal with your physical environment, and some are very technology focused. And that’s okay. The key is defining where they apply and what you are trying to achieve.

Here are some examples of functional requirements for physical security improvements:

Examples of Physical Security Functional Requirements

 

After the Functional Requirements are Complete

Key takeaways:

  • Large-scale physical security projects require collaboration between multiple internal and external stakeholders.
  • It is crucial that the buyer(s) and operator(s) work closely throughout the project to ensure the security team will be able to effectively leverage the completed project to mitigate the desired risks.
  • The functional requirements for your physical security project will ultimately be translated into a variety of documents that define precise specifications for construction/implementation.

Once you have those functional requirements, it is time to start planning the project. This is much more formalized than the steps you’ve undertaken so far. It requires internal and external resources beyond the physical security team.

Here are the key players who are likely to be involved:

There is the buyer, the person who’s going to be funding and control the project, defining the risk requirements and the functional requirements supported. This is often the facility owner or developer.

If the projects are appropriate and large enough or complex enough, you may hire a technical security consultant who will come in and help clearly define the expectations and functional requirements for physical security improvements.

Security projects often require alterations to physical structures, power supply, on-premises or cloud-based data storage – all considerations requiring specialized expertise.  Architects and engineers are often involved to determine how the project literally fits into the impacted facility or facilities.

Sometimes a project is driven purely by construction – for instance, a perimeter fence. In that case, you have the general contractor, the architect or engineer there to build out the facility. And then they may hire a technical security consultant, or work with the technical security consultant that is hired by the owner. But ultimately, they all work within the same team to support the improvement.

And then you have the security integrator or security installation contractor. They handle the actual procurement and installation of the products and technologies that must be installed. They work closely with the technical security consultant, as well as any architects and engineers involved.

There’s another “owner” on this team, and that’s the operator. Once the project is complete, the operator will be responsible for using and monitoring the technology that has been implemented – and ensuring its success. This will typically be a representative the security operations teams.

Individual team members may not have been present at the beginning of the project to define requirements and the overall measures of success. They may need to adopt new procedures or processes to ensure the desired outcome. So it’s key that the buyer and operator collaborate throughout the process to ensure the project is focused on mitigating specific risks and the result is easy for the security team to understand and deploy effectively.

For more complex physical security construction projects, the team may be much larger with multiple trades and multiple companies working together to support the initiative:

Physical Security Construction Team for Large Projects

Before construction or implementation can start, the functional requirements should be translated into the design deliverables. The most common ones you will see are floor plans, network diagrams, installation details, and equipment wiring diagrams. These all tie together with a document that serves as the specifications or specs that address everything required for the overall facility.

After the project has been implemented, you should ensure it is working as intended. A sound approach is to measure key performance indicators and collect metrics that demonstrate success. Then use this information as part of the security program lifecycle to identify areas for improvement.

To see how a threat intelligence platform can streamline the implementation of your functional requirements, please request a demo of the TopoONE platform.

 

Share This Story, Choose Your Platform!

Share on facebook
Share on twitter
Share on reddit
Share on linkedin
Share on pinterest
Share on email

Related Posts