Tom Olzak

Posts Tagged ‘Business Continuity’

IDCATU strikes Google, Apple, and Microsoft…

In apple, Business Continuity, Firefox, Google Chrome, Internet Explorer, Microsoft, Safari on February 21, 2013 at 20:47

The Register published an article today describing Adblock Plus angst over Google seemingly trying to take down their ad blocking software on Android.  See Ad-titan Google blocks Adblock Plus in Android security tweak • The Register.

While reading the article, I began to get the feeling that Google is intentionally blocking Adblock because it interferes with Google store functionality.  Interesting…

This is one more reason I am very pis… uh… angry this week.  When I first purchased my iMac last year, I was able to do 99% of what I could do on my Windows 7 laptop.  Today, Google Chrome for Mac is significantly crippled on many sites.  Further, I have to use IE 10 on my Windows 8 laptop to have access to several features I use during research.  We seem to be going backward.

When I started in IT (1983), I encountered a score of different standards from the same number of companies.  It was a compatibility nightmare until business simply accepted the IBM PC and MS-DOS as the de facto standard.  Vendors got on board or went out of business.

During the growth of the Internet, browser choices had gotten to the point that I could use the browser of my choice–the browser I felt most comfortable with–and I could be fairly confident that I would be able to be productive.  This was until recently…

Speaking only from personal experience, I believe I am suffering from a disease spreading across Microsoft, Google, and Apple: IDCATU syndrome.  As it spreads, market share and out doing the competition become more important than user productivity.  Those suffering from I-Don’t-Care-About-The-User use double-talk to assuage the unwary into believing incompatibility between solutions is for their own good. BS.

I am seriously considering moving everything to open source.  The problem is that IDCATU also forces the big players to force the creative and unafflicted to the sidelines.  Some people are simply getting too uppity for their own good… and ours.

The Internet is Broken, Part III: Response

In Application Security, Business Continuity, Disaster Recovery, Hacking, Log Management, malware, NetFlow, Network Security, Policies and Processes, Risk Management, Security Management, SIEM on January 20, 2013 at 23:12

This is the final post in a series about the broken Internet.  In the first, we looked at SIEM.  Last week, we explored the value of NetFlow analysis.  This week, we close with an overview of incident response.

When evaluating risk, I like to use as reference the following formula:

Basic Risk Formula

Basic Risk Formula

Probability of occurrence, broken into threats x vulnerabilities, helps us determine how likely it is that a specific threat might reach our information resources.  Business impact is a measure of the negative affects if a threat is able to exploit a vulnerability.  The product of Probability of Occurrence and Business Impact is mitigated by the reasonable and appropriate use of administrative, technical, and physical controls.  One such control is a documented and practiced incident response plan.

The purpose of incident response is to mitigate business impact when we detect an exploited vulnerability.  The steps in this process are shown in the following graphic.  Following the detection of an incident (using SIEM, NetFlow, or some other monitoring control), the first step is to contain it before it can spread or cause more business impact.  Containment is easier in a segmented network; segments under attack are quickly segregated from the rest of the network and isolated from external attackers.

Response Process

Response Process

Following containment, the nature of the attack is assessed.  Failing to follow this step can result in incorrectly identifying the threat, the threat agent, the attack vector, or the target.  Missing any of these can make the following steps less effective.

Once we understand the who, what, when, where, how, and why of an attack, we can eradicate it.  Eradication often takes the form of applying a patch, running updated anti-malware, or system or network reconfiguration.  When we’re certain the threat agent is neutralized, we recover all business processes.

Business process restoration requires a documented and up-to-date business continuity/disaster recovery plan.  Some incidents might require server rebuilds.  Business impact increases as a factor of the time required to restore business operation.  Without the right documentation, the restoration time can easily exceed the maximum tolerable downtime: the time a process can be down without causing irreparable harm to the business.

Finally, we perform root cause analysis.  This involves two assessments.  One determines what was supposed to happen during incident response, what actually happened, and how can we improve.  The second assessment targets the attack itself.  We must understand what broken control or process allowed the threat agent to get as far as it did into our network.  Both assessments result in an action plan for remediation and improvement.

The Internet is broken.  We must assume that one or more devices on our network is compromised.  Can you detect anomalous behavior and effectively react to it when the inevitable attack happens?

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: