Dealing with IT Standards and Requirements

The days of flying under the radar of IT compliance are coming to an end

provided by: 

For some years now, IT departments have had compliance software available to them that goes out onto the network and automatically examines connected equipment, identifying any that do not meet IT's requirements.

When I received the answers in response to this column's question — which asked if you have ever put security systems onto the corporate network without collaborating with IT first — I realized that an introduction is in order about this kind of technology. James Connor, currently the principal of security consultancy N2N Secure (www.n2nsecure.com), and formerly the senior manager of Global Security Systems at Symantec, provided the introducton above — sooner or later, every security manager with security systems can expect to be affected by compliance software.

Any new electronic product that hits the shelf from now on will be looking to leverage the network and take advantage of the capabilities that come with a more mainstream approach to what will essentially be just another "endpoint," as our IT department counterparts call them. Computers, printers, conference phones and so on are called endpoints because they are a point at which data is received, processed, and sent back to other devices on the network. They are an active device at the end of a network connection. Now cameras and card readers, for example, are becoming network endpoints. Endpoints that are not subject to a service level agreement (SLA) with IT, and which are not actively being managed by IT or by a contracted service organization according to IT requirements, are referred to as "orphan endpoints."

One truth is that we will be able to move forward from our traditional world of propriety security devices and systems solely because we want the capabilities of new technology. A primary driver is that new IP products are offering a lower total cost of ownership (TCO) by utilizing what every company already owns — its own IT infrastructure.

On one hand, security practitioners want capabilities that the new technology has to offer. On the other hand, most practitioners are not prepared to exist in this new and seemingly hostile environment of SLAs, compliance and internal governance that dictate the management and lifecycle of existence for devices that reside on a managed network infrastructure.

As new IT compliance products emerge to assist the weary IT/IS manager, security practitioners will see e-mails that look something like this:

This system (Windows 2003 server at IP address 174.16.254.1) is very vulnerable due to:

  • Unmanaged SAV (Symantec AntiVirus) client
  • Unprotected ports
  • Not a domain member
  • Unmanaged (no domain group policy applied) etc.
  • Not monitored
  • No support/maintenance SLA exists
  • Not server list for monthly security patch deployment

As Server Operation manager, I can not allow this server plugged onto the network.

The days of deploying DVRs, Physical Access Control Systems (PACS) and other orphan endpoints with anonymity and flying under the radar of IT compliance are rapidly coming to an end. This is a good thing for those of us who wish not to have physical security systems ironically end up as the biggest threat to the logical security of our corporate enterprise.

Q: Have you put security systems onto the corporate network without collaborating with IT first. If so, what was the result?

A: A few years ago we put a few devices on our security LAN just to try them out. A few hours later we got a call from IT about "rogue IP addresses" on our LAN. We were surprised that they knew about it. We learned that they have scanning software that checks the network for non-registered IP addresses, and that also checks the equipment for known vulnerabilities (open computer ports, for example). That was the start of our collaboration with IT.

Security manager, port authority

A: We put some additional workstations on our company network, and connected our access control system server to the company network using a second network card in the server. The purpose was to allow us to access the access control and monitoring software from more locations on our campus. By trial and error, we found IP addresses that were not in use and this worked for a while. Then suddenly the connections weren't working any more, and we couldn't find any IP addresses that worked. That drove us to call IT and find someone we could get tech support from. They gave us some documents that contained the requirements for computers and devices to be placed on the network. Once we patched the operating systems and installed anti-virus software, they helped us put them back onto the network.

Security manager, commercial real estate management company

New Questions

Q: How long have you been collaborating with IT about networked security systems? Who made the first move, the Security or IT department? E-mail your answer to ConvergenceQA@go-rbcs.com. We don't need to reveal your name or company in the column, but we'd be happy to credit your for your quotation.

Ray Bernard is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities. He is founder and publisher of The Security Minute 60-second newsletter (www.TheSecurityMinute.com). Visit www.go-rbcs.com or call 949-831-6788 for more information.

author: by Ray Bernard, PSP, CHS-III


Related Articles
- Navigating Codes and Standards and More
I regard equipment connected to line voltages as appliances and look for the UL label, and if I have a concern, identify the specific listing number to be certain the device is appropriate for the application.
- Sharing Standards
- Making the Right Decisions
- Bring Order to Your Open Source
- Mass Notification Benefits Many
- From Software to System to Service
- Ready For the Semantic Web?
- Mapping the Green Road
- Preparing for High Media eLearning
- Industry Standards
Regional Articles
- Dealing with IT Standards and Requirements Alabama
- Dealing with IT Standards and Requirements Alaska
- Dealing with IT Standards and Requirements Arizona
- Dealing with IT Standards and Requirements Arkansas
- Dealing with IT Standards and Requirements California
- Dealing with IT Standards and Requirements Colorado
- Dealing with IT Standards and Requirements Connecticut
- Dealing with IT Standards and Requirements DC
- Dealing with IT Standards and Requirements Delaware
- Dealing with IT Standards and Requirements Florida
- Dealing with IT Standards and Requirements Georgia
- Dealing with IT Standards and Requirements Hawaii
- Dealing with IT Standards and Requirements Idaho
- Dealing with IT Standards and Requirements Illinois
- Dealing with IT Standards and Requirements Indiana
- Dealing with IT Standards and Requirements Iowa
- Dealing with IT Standards and Requirements Kansas
- Dealing with IT Standards and Requirements Kentucky
- Dealing with IT Standards and Requirements Louisiana
- Dealing with IT Standards and Requirements Maine
- Dealing with IT Standards and Requirements Maryland
- Dealing with IT Standards and Requirements Massachusetts
- Dealing with IT Standards and Requirements Michigan
- Dealing with IT Standards and Requirements Minnesota
- Dealing with IT Standards and Requirements Mississippi
- Dealing with IT Standards and Requirements Missouri
- Dealing with IT Standards and Requirements Montana
- Dealing with IT Standards and Requirements Nebraska
- Dealing with IT Standards and Requirements Nevada
- Dealing with IT Standards and Requirements New Hampshire
- Dealing with IT Standards and Requirements New Jersey
- Dealing with IT Standards and Requirements New Mexico
- Dealing with IT Standards and Requirements New York
- Dealing with IT Standards and Requirements North Carolina
- Dealing with IT Standards and Requirements North Dakota
- Dealing with IT Standards and Requirements Ohio
- Dealing with IT Standards and Requirements Oklahoma
- Dealing with IT Standards and Requirements Oregon
- Dealing with IT Standards and Requirements Pennsylvania
- Dealing with IT Standards and Requirements Rhode Island
- Dealing with IT Standards and Requirements South Carolina
- Dealing with IT Standards and Requirements South Dakota
- Dealing with IT Standards and Requirements Tennessee
- Dealing with IT Standards and Requirements Texas
- Dealing with IT Standards and Requirements Utah
- Dealing with IT Standards and Requirements Vermont
- Dealing with IT Standards and Requirements Virginia
- Dealing with IT Standards and Requirements Washington
- Dealing with IT Standards and Requirements West Virginia
- Dealing with IT Standards and Requirements Wisconsin
- Dealing with IT Standards and Requirements Wyoming
Related Articles
- Navigating Codes and Standards and More
I regard equipment connected to line voltages as appliances and look for the UL label, and if I have a concern, identify the specific listing number to be certain the device is appropriate for the application.
- Sharing Standards
- Making the Right Decisions
- Bring Order to Your Open Source
- Mass Notification Benefits Many
- From Software to System to Service
- Ready For the Semantic Web?
- Mapping the Green Road
- Preparing for High Media eLearning
- Industry Standards
Rate Article
     
Articles Insider

Rss   Delicious   Digg   Add To My Yahoo   Add To My Google   Bookmark   Search Plugin

Topics:
Advertising Engineering Home Services Retail & Consumer Services
Business Services Entertainment Industrial Goods & Services Software
Career Family Insurance Technology
Cars Financial Services Internet Telecommunications
Computer Hardware Food & Beverage Legal Transportation & Logistics
Construction Health Pets Travel
Education Home Electronics Real Estate Wedding