• White Paper-Jamming at the Gate, Part Three

    We have now looked at offensive planning (Part One) and at defensive planning (Part Two), and we have discussed vehicle inspection, blast resistant modules (often Ballistically uparmored) or use as control rooms, and at data acquisition in large complex systems. How can it all be tied together not just in an Integrated Security Plan document but also how the architect of the entire system might leverage one aspect and/or another to create a cost effective and quickly integrated system for a client/command. We also discussed securing SCADA nodes and everything discussed in that posting applies as well.

    Basic architecture considerations include:

    Hardened perimeters, featuring excellent camera and other sensor coverage
    Excellent PSIM (Physical Security Information Management) system integrating—
         Cameras and Overt Sensors
         Overt sensors
         Vehicle Inspection system with integrated PSIM interface of its own (undercarriages and license plates)
         Data acquisition system merging all sensor and subsystems into one “nexus”
         Hardened power and power conditioning subsystems
         Hardened command center (aka “control room”)
         Hierarchically linked upstream command centers with ‘Kill Switch’capability for lower echelon command      centers
    Potentially dangerous subsystems are more intensively monitored

    Often overlooked items of a fully stocked toolbox include spectrum analyzers to monitor the electromagnetic spectrum around the perimeter – and at the gate, fielding more covert sensors than overt sensors in many cases (esp. vibration, pressure, microwave, and electrical conductivity), and creating multilevel, multiply backed-up recorders and at least one in an offsite storage site (the “cloud” works very well for this).

    Something often missing in many organizations’ integrated security plan is the three steps of Probe, Analyze, Rework. That is, run real attackers against your system, study to see how and where they penetrated your perimeter or your internal IT security, and then make a plan to fix it and execute the plan promptly. THEN, do it again.

    In our write-up on 7 Critical Considerations we discussed the trade-offs between cost and quality of security. We noted there that there are only these few major categories to work through (and through, and through):

    Consideration #1: Requirements Definition
    Consideration #2: Cost

    Consideration #3: Ease of Installation and Maintenance
    Consideration #4: Disruption of Process
    Consideration #5: Overt and Covert Systems
    Consideration #6: Complexity of Control Functions
    Consideration #7: Flexibility and Scalability

    We focused on Threat, Vulnerabilities, Value of Assets being Protected, and Cost of Failure as the four leveling concerns – that is, every decision needs to be seen as driven by and having an impact upon those four matters.

    And, importantly, we noted that the security program (and the ISP) must be “living” documents, updated as new intel comes in, as the facility grows and changes, as assets come in or are taken away, and as growth and change in the security program occur the fact that the leadership must continuously reevaluate the reliability of the system.*

    All-in-all, most ISPs are the product of a team. This is so because there are myriad aspects, multiple systems, often multiple commands (owner and tenants), and the threat matrix is always changing.

    One reason we love this work is it is a demanding and curious blend of high technology, force protection, and mission readiness.

    It seems to be like the world news – just wait a minute and something will happen to change everything!

    *Typically, system reliability becomes more and more a problem with increases in numbers and/or complexity of subsystems/components added.

    You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

    Comments are closed.