Enterprise Interactions for Physical Security

So, as promised a week ago, here are some scenarios for physical security systems interacting with enterprise systems, and even through the enterprise to other enterprise-enabled buildings systems.

Hotels, Customer Service and Energy.

Hotels put a lot of effort into their customer relationship management. Building space, if well operated, cost the same in similar cities. Beds are beds, as long as they are clean. Hotels compete for customer loyalty to develop preferences that make the consumer check their hotel chain first rather than merely going to hotels.com.

The vision of Hotel Technology Next Generation (htng.org) includes rooms that respond automatically to the customers preferences. These could be warm, cool, or even green with a carbon units saved report printed on the room-check-out.

A proximity chip on the hotel’s room key could allow a guest easy keyless entry to the lobby late at night. The security system could alert the enterprise of the guest’s arrival, and notify the room to prepare the environment the guest likes. Put the same proximity chip on the guest’s frequent customer card, and the front desk could be alerted for expedited check-in. The regular guest could even receive an instant text message on his phone, sending him directly to his room without check-in. The guest’s arrival could notify hospitality services to deliver the guest’s favorite martini or late-night hot chocolate directly to the room within minutes of arrival.

Commercial Maintenance and Federated Identity Management

Commercial building owners face several additional expenses above and beyond repair bills, when a mechanical system needs maintenance. Someone must be tasked to wait around for the repair man. They then let them in to the normally secure areas where the mechanical systems are installed. They may wait around to verify the actual hours on-site by the expensive repair personnel.

With enterprise interaction and federated identity management, the service personnel could gain direct access to the secure areas using their own company badge and their time on site could be tracked automatically.

When the owner and the service organization establish a contract, they would set up the identity federation. The access control system would then refer the security token of the service technician to the service organization for authentication. The authentication process would be the same whether the identity token was merely the badge or biometric data exchanged by the BIAS (Biometric Identity Assurance Services) standard. We now know who the service technician is.

Authorization would involve business processes in both organizations. The owner’s system knows that a service issue exists one the equipment and that the service order has been issued. The service provider knows which technician is assigned to that work order, and can pass the work order back with the authentication. While the work order is open, the technician can be admitted and his comings and goings tracked.

I will add more scenarios soon, including emergency management. Until then, remember that security is not about locking the door; security is about using situation awareness to respond the right way at the right time.

Enterprise Integrated Security

It’s all too easy to get caught up in energy this year. It is easy to forget that energy was only one of the reasons I was drawn to enterprise interactions for building systems. There are compelling reasons to integrate physical security systems with enterprise systems and their techniques. Physical security is typically broken up into three areas; access control, intrusion detection, and monitoring. These systems rarely interact unless installed by the same vendor, and even then, significant integration may be required.

Security is not about locking the door; security is about responding the right way at the right time. The true core of security is situation awareness.

Last week, I was awakened in hotel by a couple letting themselves into my room. It was clear that they had a pass key, and were surprised that the room was occupied. I had checked in after 10:00. There is no doubt in my mind that this was a tryst planned earlier in the evening when the hotel systems still showed the room as vacant. There were minor problems in housekeeping, unusual in a high end hotel, such as hair on the bathroom sink, that may have not been due to insufficient housekeeping. The hotel manager said he would send a security officer to read the access log on that door, an officer who never showed.

Was it a romantic tryst? Was it a side deal arranged with the one of the numerous prostitutes working the bar at this Embassy Row hotel? In either case, it is a system failure and a liability risk caused by non-communicating, siloed system.
Access control is token management, whether the token is an old brass key, or an updated computer token or biometric ID.  Large institutions may have token approval driven by central databases, but these databases rarely interact well with enterprise records. Personnel records, hotel registrations, and contracting status are obvious interactions. These systems usually only simulate such interactions, perhaps through daily or weekly batch updates. Access to hotel common areas often works until your original check out date, even if you leave early. Hotel room keys often continue to work until your original check out date, even after you change rooms.

There are some simple interaction across IT and Access Control silos that I have seen, one that today require unusual integration. In a high security facility, a user’s network login is disabled if his access card has not come though the front door today. In a chemical plant, assigned laptops only get network access in certain areas if the correct person has entered the room.

Intrusion detection begins with the night watchman and is automated as vibration sensors on glass and contact closures on doors and sashes. These may be wired back to a central monitor, and they may be able to recognize unusual local conditions, such as a door propped open. It is usually difficult to find patterns of potentially harmful behavior. An alert, intelligent security officer may spot patterns, and anticipate intrusion, but these decisions must be informed by enterprise activities. For example, a catering staff may routinely prop a series of doors open an hour before a reception. This may be OK, except if the event is a presidential debate. Few systems have the situational awareness of business operations to automate the process; those that do require significant customization.

Because network and information security is potentially vulnerable from anywhere on the planet, there is a competitive market of tracking patterns of events and recognizing unusual patterns on a user by user basis. As criminal attacks recognize these, the attacks become more sophisticated, too. A couple years ago, credit card information stolen through Brazilian servers was re-appearing within 24 hours on East European markets before surfacing as fake cards in New York City. Different individuals might by a small breakfast, and lunch across town, before making a significant purchase in the afternoon. The whole scheme was predicated around gaming the fraud detection systems. The Policy Based Event Management systems are now able to catch such rote attacks, as well as many others that I will not describe here.

True security is always about situation awareness. Unless security systems are aware of wider enterprise issues, they are not aware of much. Security systems can also contribute awareness to other operations in the enterprise. Later this week, I will try to post some leading scenarios for integrating access control, with enterprise operations, emergency response, and with federated identity management.

Divvying Up Grid Interoperability

The NIST Grid Interoperability Workgroups began by splitting into work groups along traditional market segments. I think the initial cuts (I2G, B2G, H2G&V, T&D) (Industry, Building, Home (and vehicle) to Grid, and Transmission & Distribution) were necessary, I think keeping them makes it far too easy to pave the cow paths, to streamline existing market models while allowing minimal room for new markets to develop.

As I look across the groups, they feel to me as if they are split up incorrectly. The home deserves the same DR possibilities as does the office. A hospital may want the same grid information as does the data center. The privacy liability incurred by the utility developing intimate knowledge of the home operations may be as great as they would incur in a bank.

Background

I was talking to representatives from The Green Grid yesterday. The Green Grid is about Grid Computing, not the Power Grid. Grid Computing is the most efficient process ever defined for converting electricity to raw business process, with a hundred % waste as heat.

The Green Grid concerns are the immediate supply chain issues for its raw materials and support requirements, primarily energy and cooling. The Green Grid questions, which it wants to ask to each battery, each power strip, each switch panel, each transformer in each substation, and even the grid as a whole:

• How much more capacity can you give me?
• How reliable do you feel ? Any risk you will fail in the near future? (same question whether battery or empty diesel fuel tank or overheating transformer or extreme DR event on the power grid)
• What price is the current power? What about the additional capacity? (This should arguably factor cost of diesel, or natural gas, or even inefficiency of battery, but that is another question.)

These same questions are essentially the same as they ask the building’s cooling systems.

These questions are also the questions I might want to ask the thermal storage in the basement, or the PE power on the roof. If I am using waste heat from the Data Center for re-heat in my AC, I may want to ask the same questions. These are the generic questions to ask an energy resource within or without the building, whether in the off-grid home or in the site generating neighborhood, or in the office.

My memory stick is an instance of a USB storage device, and so has a user interface on my computer that presents the same as an internal disk drive. In the same way, these are all attributes of sources of energy, and make no pre-suppositions about the devices or process behind them. This kind of interface enables interoperability while not preventing future innovations, even radical new technologies.

I think we should incorporate the The Green Grid abstractions into the DEWG interoperability suite. But where?

My Proposal

I have proposes that we consider the interactions into a few business/semantic groupings. Grid interoperability should consist of surface interactions; deep interactions are a barrier to scalability and to innovation. The semantic grouping I propose are:

Capability & Reliability: (The Green Grid interactions, to be used in building system domains as well) Capacity / Capability / Availability (including time windows) / Anticipated Reliability / Marginal Price

Market Operations: Power Use curves, Negotiation & Contracts, Offer and Acceptance, Scheduling options, Periodic price curves. Settlement. Contracted Curtailment? DR

Multi-party & Mobile transactions: PHEV, Non-Utility vendors, identity, transactional charge override

Operational Information: does not need to flow across domains, primarily T&D for this discussion. Allied domains, say, inside building systems aligned on results rather than procedures.

Security: borrow compositional security from other domains.

Billing & Charge Processing: borrow from other domains

Attributes & Amenities: Carbon, Wildlife, Location…Optional attributed for later definition and market building.

Do I have them all?

Standards Buzz: WS-DD, DP, IPSO, et and Internet 0

There sure is a buzz in standards this week, especially in standards that can help change our relationship to the built world: buildings, systems, and energy. I’m watching them and trying to put things together. I haven’t yet, but this is what I am seeing.

• A new OASIS group has started to standardize web services for device discovery (DD), Device Profiles (DP) and SOAP over UDP. DD and DP are already used by many printers. The committee includes the Operating System (OS) makers (of course), the Printer makers (of course), the enterprise software makers (well that’s more interesting) and other device makers, including Schneider Electric, one of the largest makers of building systems, meters, and electric grids. When the oBIX committee (the Open Building Information Exchange) was formed, we had numerous industry-specific sub-committees. Several of these had to disband after Schneider had bought up a quorum. It is intriguing to see Schneider now back, in enterprise web services standards, working with such players as SAP and Microsoft.
• IPSO is a new industry alliance promoting the use of IP (Internet Protocol) for smart objects, where smart objects are all the systems sensors, meters and so on that make up the hidden world of engineered systems. They are creating what they are calling “the Internet of Things” connecting physical objects with the global Internet. IPSO aims to tackle energy distribution and consumption, home automation, and work environments.
• I see these converging with the Internet 0 efforts to bring full connectivity and networking to devices “too small to be networked”
• NIST, as I have written before, is fast-tracking efforts to define interoperability around the power grid.
• SOAP over UDP is an effort to bring the full power of compositional messaging, with all that means for the enterprise to a lighter weight stack appropriate for small devices. Interoperability to me means interoperability with the business and people that inhabit the homes and offices.

I do not know where these fit together. I do think they are pursuing the same goals in the same way.

To me, these initiatives will become more interesting when they start using more compositional technologies. Perhaps Service Component Architecture (SCA), will be used to connect disparate systems together into common service definitions. Perhaps Policy Based Event Management will be used to let companies craft fine-grained responses to external conditions.

Right now, I wake up every day and wonder what will be in my in box.