Tom Olzak

Archive for October, 2010|Monthly archive page

Are You Ready for the Rise of Non-IT Devices

In Access Controls, Application Security, Business Continuity, Cloud Computing, Control Systems, Data Security on October 23, 2010 at 15:17

Security managers and their organizations are just starting to understand what it takes to keep traditional network-attached devices secure.  Servers, desktops, laptops, switches, routers, and even smartphones fall under IT’s security policies and are protected by layered controls.  IT’s management of data security naturally extended to writing and enforcing policy on them.  Further, there are a plethora of best practices to choose from when constructing a security framework in which traditional devices reside.  And so just as we get our balance, a new challenge arises—devices that fall outside our data security policies and existing best practices.

The number of non-IT network-connected devices is rapidly increasing.  As organizations find it easier to achieve compliance with non-data related regulations by using automation, and as they learn that they can squeeze a few more dollars into EBIT by automatically adjusting utility use, for example, the demand for these devices is accelerating.  However, many security managers may find themselves in conversations in which they either have no idea about the security risks associated with these devices, or  in which they are forced to stop money-saving projects because they are not ready to handle the additional controls.  In either case, they may find themselves updating their resumes.

What are Non-IT Devices?

Non-IT devices fall into two categories: sensor and control.  Sensor devices collect, aggregate, and report status of key elements of the real world.  Examples include:

  • Security cameras
  • Devices that monitor key production events
  • Energy meters

Control devices not only monitor real world status, they can also affect it by automatically making changes to it.   Examples include:

  • Environmental control systems
  • Security systems that react to events in real-time
  • Temperature controls that maintain heat or cold within acceptable ranges

Devices in these categories are not new to the workplace.  What is new is the increasing demand to connect them to the network.  The traffic resulting from this connectivity is known as machine to machine (M2M) networking.

Security Concerns

When I first encountered M2M networking, the most obvious security challenge was vendor access to the systems.  Access for support is important to ensure continued operation, and sometimes outsourced monitoring, of sensor input.  In many cases, vendors will also make adjustments via control devices to maintain environmental or production tolerances within limits defined by the customer.

For example, there are government health regulations covering the temperature of water in dishwashers used in skilled nursing facilities.  The long term health care company for which I worked decided that compliance was more probable if the water temperature was monitored at all times.  So it contracted with a vendor that specialized in this.  The vendor supplied all connections to the dishwashers and to the vendor-supplied PC used to collect the temperature information.  However, vendor staff needed access to the system 24/7.  This required them having access to our network.  We eventually figured this out, but it required weeks of planning, testing, and implementation of a vendor-specific VLAN to allow access to the control systems while blocking access to the rest of the network.

Although the monitoring of water temperature lacks sensitive data, this is not the case with security cameras.  At the same health care organization, facility administrators increasingly demanded implementation of network-connected security cameras.  In addition to vendor access for maintenance, a new challenge was introduced; the output from cameras had to be stored on the local facility server.

Two major issues immediately arise when taking and storing video.  First, HIPAA requires that patient information, including pictures, must be tightly controlled.  Second, legal discovery would require searching through or providing all video to the requesting party.  We had to work through these issues before allowing implementation.

The Final Word

We can’t stop the increasing use of non-IT devices.  Instead, we must prepare to protect them and our network.  I recommend starting by writing a policy that governs implementation and use of vendor- or operations-managed, non-IT devices.  I found that this helped people understand what they could or could or could not do when selecting a solution.  The policy should include management’s expectations regarding anti-malware protection and patch management for the M2M systems.

I also recommend taking another look at your network and security architectures.  Make sure you have the necessary walls built between M2M network segments and the rest of the network.  For example, non-IT devices and IT devices may have to share the same wires and network components, but they don’t have to ride on the same VLANs.

Give business continuity a chance…

In Business Continuity, Computers and Internet, Disaster Recovery, Risk Management on October 16, 2010 at 11:25

Business continuity is the practice of understanding critical business processes and ensuring their availability.  Disaster recovery is a component of business continuity.
Understanding business processes includes answering the following questions:

  1. What are the manual tasks that support the process?
  2. What are the human and technical resources necessary to enable the process?
  3. What other processes feed data to or receive data from this process?
  4. Is it reasonable and appropriate to build redundancy into the system?
  5. What is the maximum tolerable downtime of the process (how long can the process be broken without causing irreparable harm to the business)?
  6. Based on current capabilities, what is the recovery time if one or more of the components is broken or missing (including processes that feed this process)?
  7. Based on current capabilities, what is the recovery time following a catastrophic event (disaster recovery)?

It takes a group representing a cross-section of the organization to answer these questions.  Note that the planning is around processes, not systems.  Processes are enabled by systems and manual tasks.  For example, questions 4, 6, and 7 should include manual workarounds if automated tasks fail.  (A process is something like processing payroll with expected outcomes including checks for employees, tax payments, etc.)

Once the questions are initially answered, a remediation action plan is created to mitigate risk (shorten recovery time).  Risk mitigation takes two forms: interim and long-term.  Interim mitigation includes workarounds to enable critical outcomes while recovery tasks are performed.

When the action plan is complete, the team should once again answer questions 6 and 7.  If recovery times are not shorter than maximum tolerable downtime, additional remediation steps should be identified.  This cycle repeats until maximum tolerable downtime exceeds recovery time.

Government Dysfunction Strikes Another Blow for Insecurity

In Access Controls, Business Continuity, China, Cyber Espionage, Government, Hacking, Network Security, Password Management, Policies and Processes, Risk Management, Security Management, Vendor Management on October 12, 2010 at 12:51

For many years, even before the Internet, changing default access codes, passwords, and other vendor assigned information was considered a basic no-brainer.  And I understand normal people (non-IT) not getting it.  After all, if it wasn’t a good password, why would a vendor assign it…?  And who wants to argue with a support guy on the phone who can’t understand why you changed it?  I get it.  However, when our government doesn’t see the value in the change, we have a big problem.

According to an article last week in the New York Times,

[University of Michigan researchers] infiltrated the District of Columbia’s online voting system last week. They changed all votes for mayor to Master Control Pro and elected HAL 9000 the council chairman. The blaring University of Michigan fight song played whenever a new ballot was successfully cast” (Wheaton, 8 Oct 2010).

To be fair, this is a pilot project by the District’s Board of Elections.  However, I always thought “pilot’” meant seeing how it works in the real world.  So it should also mean setting security for testing system trust.  One reason why this is necessary was included in the same article:

“[Professor J. Alex Halderman] said he also saw signs that computer users in Iran and China were trying to crack the system’s master password — which his team obtained from an equipment manual. (Network administrators had never changed the four-character default password.) He said that the foreign hackers were probably not specifically trying to break into the District’s voting system, but that they represented a threat nonetheless” (ibid.)

In addition to immediate attempts by our “enemies” to hack into the system, we decided to practice global good will by leaving the vendor password in place for anyone who wanted into our system.  What a novel idea regarding how to meet the cyber-crime and warfare challenges we increasingly face.

In case you haven’t yet gotten the message across to your network engineers or internal support personnel, this might be something you can use as an attention-getter (instead of the bat you’ve placed strategically next to your filing cabinet.

This is just one more example of the dysfunction of our government information handling capability.

%d bloggers like this: