| |
|
 When it came to building mission critical facilities the founders of iFortress saw a need to provide an alternative to the standard construction practices currently being assumed to protect data and technology centers, tele-communication posts, documents, electronic storage area networks (SAN), information links and assets. Until now, structural material choices have been few and far inadequate to provide the level of protection required for sensitive assets. Required protection against the type of simultaneous, multiple threat scenarios that adversely and regularly affect the way in which we as a society have come to depend on the uninterrupted flow of information and commerce.
 Initially, our objective was to engineer a revolutionary product that provided a solution to a construction need/problem. As we began our diligence we quickly discovered that not only was there a significant need for a product/solution like what iFortress was proposing, but we also came to see that in order for our solution to be understood we had to establish a basic language that would accurately represent the approach that iFortress was taking to address this need. So, we created a specific vernacular to best and simply describe the way in which we were proposing to solve a problem.
Physical, Operational, and Logical security principles were already well practice, and the language surrounding each was just as well practiced and universally understood. Additionally, the undeniable implementation of each was absolute. These incumbent security principles had very mature markets and finding a place for our solution to fit in was definitely posing to be a challenge.
|
From the onset, as we introduced iFortress, all people seemed to hear was that our solution was either another form of Physical Security – access control, protecting the operation from human (physical) intrusion, or an Operational Security product protecting centers against fire with a reactionary suppression-type control device. Our task became one of clarifying our message, we had to drive the market’s focus on to the walls, the floor, the ceiling; in a nut shell, the facility (or the structure) itself. Thus, the terminology ‘structural security’™ was formed and with simple supporting verbiage, the concept and language was readily accepted. However, at first it was kind of, “Structural security; what’s that?” But, with a brief explanation and within a very short time, the idea stuck. That was nearly six years ago. Today, we’ve started to see business cards with the title ‘Director of Structural Security’. Most excellent!
The next step in iFortress’ history was to define exactly what structural security™ meant (e.g. what exactly it encompassed in terms of the actual threats). We identified this as a discipline required to protect mission critical technologies and assets (side note: ‘assets’, we use this one a lot to explain ‘assets’ – a furrier’s mission critical asset is fur and it is just as vital or critical to his/her business and just as vulnerable to loss or damage caused by human or environmental threats as are information technologies – therefore, ‘technologies and assets’) against fire, water, heat, dust, humidity, dust, smoke, acrid gasses, RF, EMI/EMP, theft, vandalism, unauthorized access, explosions, bullets, construction hazards; this brief of tortuous events quickly surmises a long list of human and environmental influences that reek regular havoc on highly sensitive operations that are crucial to a business’ survival.
We saw that there were some products available
in the market that invariably served to protect against a select and narrow
spectrum of these threats (i.e. fire walls that did a great job against
flames), but just as invariably these measures did very little to protect against the parallel threats that are |
 |
|
normally and simultaneously associated with a complex threat like a fire (e.g. ‘if it weren’t the fire that killed ya, it was the flood that came with trying to put it out.’). There are shielding methodologies, which use basic construction resources to keep out electronic interference or espionage, but ultimately these tend to create other problems, like fire traps or acting as an oven conducting the thermal rage when a fire happens. Also, there are acoustic panels, even structural barriers that are excellent for mitigating things like sound and/or vandalism, but when it comes to stopping the pandemonium caused by a leaking toilet, these extensive (and costly!) efforts do nothing.
Structural security™ cannot simply be the deployment of a ‘myopic’ form of protection. The complexities associated with structural breaches are as dynamic as the solution itself has to be. In order for a structural security™ solution to be effective, it has to provide complete protection against a wide range of multiple threats that can and do occur simultaneously.
After years of trial and error, and with several impressive successes we proudly introduced the iFortress line of tested and approved (IBC compliant and ASTM listed) structural security™ products to the market that meet this mandate; this security imperative. Regardless of what threat is your concern, rapidly build an iFortress and the threat will be mitigated.
So, what began as an objective to engineer a security solution, wound up being the creation an entire security industry; that of Structural Security™.
With today’s ‘speed of business’ demands, the accentuated features of the iFortress technology is its rapid deployment; build a thousand square feet in days, thousands of square feet in weeks, not months, even years. And with today’s heightened dependency on the uninterrupted flow of information, implementing every measure of security available, all disciplines - Physical, Operational, Logical, and Structural, is an imperative and the absolute benefit inherently derived when building an iFortress. |
|
|
