Tom Olzak

Archive for the ‘Vendor Management’ Category

SAS 70 replacement: SSAE 16

In Business Continuity, Cloud Computing, Data Security, Government, Network Security, Policies and Processes, Regulation, Risk Management, Security Management, Vendor Management on February 28, 2011 at 22:24

I’ve never been a big fan of SAS 70, even though it seemed to many  like a great way for an organization to tell the board and its auditors that it practiced due diligence.  You know, ” hey look, I got a SAS 70 from the service provider.  See, they’re secure.”  Not so fast, bucko.

The SAS 70 was never intended to be a test of the effectiveness of an organization’s security controls.  Rather, it simply checks to see if controls are in place–controls as defined by the audited organization’s own management.

In the article, SAS 70 replacement: SSAE 16 – CSO Online – Security and Risk, CSO’s Bill Brenner takes a look at something that may strengthen SAS 70… a replacement.

 

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.

Good Planning Requires Follow-up

In Backup, Business Continuity, Cloud Computing, Disaster Recovery, Security Management, Vendor Management on August 31, 2010 at 07:29

Many organizations still believe that having a great business continuity plan, complete with a solid contract with a third-party recovery partner, is enough to protect them from the inevitable.  As American Eagle Outfitters found, however, this is not enough.

According to Evan Schuman from StorefrontBacktalk.com, which monitors retail Web sites, the outage began with series of server failures.

Schuman, who said he spoke with an unnamed IT source at American Eagle, said a storage drive failed at an IBM off-site hosting facility. That failure was followed by a secondary backup disk drive failure. Once the drives were replaced, the company attempted a restore of about 400GB of data from backup, but the Oracle backup utility failed, possibly as a result of data corruption. Finally, American Eagle Outfitters attempted to restore its data from its disaster recovery site, only to discover the site wasn’t ready and could not get the logs up and running.

“I know they were supposed to have completed it with Oracle Data Guard, but apparently it must have fallen off the priority list in the past few months,” the source told Schuman.

via American Eagle Outfitters learns a painful service provider lesson – CSO Online – Security and Risk.

This is the description of events leading to an eight-day outage for the company’s customer-facing website.  There are one or two lessons for all of us here.

First, when was the last time American Eagle asked IBM for its processes for dealing with unusual outages?  How often did they review IBM’s processes for testing incident response?  This is as much American Eagle’s responsibility as it is the off-site vendor’s.

Second, when was the last time backup tests were performed?  What are the requirements for this in the contract and how is compliance validated?

Based on this article, there’s no evidence that American Eagle was intentionally negligent.  They simply made the mistake of assuming; that is, assuming their service providers were practicing due diligence.  When using cloud or any other third-party services, we still have a responsibility to inspect what we expect.

A model for vendor due diligence

In Cloud Computing, Data Security, HIPAA, Policies and Processes, Risk Management, Vendor Management on May 19, 2009 at 03:01

Many organizations today rely on third parties for varying levels of information processing.  This is especially true where hosted services provide core applications required for a critical business process.  Sharing business process implementation with outside entities may require not only sharing of sensitive information.  It may also require reliance on the integrity of financial data derived from vendor systems and imported into an organization’s financial reporting applications.  Although there are countless ways to structure such relationships, one factor remains unchanged across them all; the responsibility for protecting sensitive or regulated  information rests on the shoulders of the organization which collected it from customers and patients, or protects it on behalf of investors (i.e., intellectual property).

The steps necessary to practice due diligence are simple.  When followed, they provide reasonable and appropriate protection.  Figure 1, from a recent ISACA Journal article, depicts a simple model built upon six basic activities, extending from before contract signing through the life of the business relationship (Bayuk, 2009).  Note the recommended organizational entities involved with each activity.

Figure 1

1. Identify data.  There is no reason to provide an entire database to a vendor when a few fields will suffice.  Define the process the vendor you expect the vendor to perform and document the minimum data elements required.  Include only these elements in any transfer of data.  Since your data is already classified (I’m making an assumption here), internal policies dictate how it is to be handled.  Use these policies as the basis for contractual wording which compels the vendor to handle shared information in a way you expect.

2.  Implement internal controls.  Just because you agree not to provide more information than necessary doesn’t mean your staff will comply.  First, they have to know what information is allowed to pass.  Second, controls must exist to monitor for mistakes.

3.  Specify requirements.  Requirements include not only what data is exchanged.  They also have to specify how the data is protected while its moving between networks or at rest.  The requirements should adhere to data classification policies identified in the Identify Data activity.  Identify any additional controls and include them in the contract.

4.  Identify vendor processes.  Up to this point, most of the work revolves around your internal processes and expectations.  Now it’s time to see whether the vendor can meet management’s requirements for safe handling of its information.  Ask questions about basic security controls in place.  Make sure you understand how access is controlled and whether a good disaster recovery plan is in place and tested.  Overall, make sure the security framework, including operating processes, will adequately protect your information.  Will the vendor be able to meet your requirements?  Again, make sure current acceptable controls are included in the contract as well as steps to fill gaps discovered during the process review.

5.  Map 3 and 4.  At this point, you want to identify any issues which might elevate risk to an uncomfortable level.  Verify controls claimed by the vendor actually exist.  Then map the results of 3 and 4.  Are there any gaps which the vendor is either unwilling or unable to remedy?  Report these potential vulnerabilities to management for a risk review.

6.  Make assessment.  Perform this activity at the point at which the vendor and you contractually agreed that all controls were to be in place.  Repeat this assessment periodically during the life of the contract.  Assessments should be performed by your internal audit team or by a disinterested third party.

Bayuk’s model is simple, and it provides a framework upon which to build a vendor due diligence process which works for your organization. 

Works Cited

Bayuk, J. (2009, April).  Vendor Due Diligence, ISACA Journal, v3 2009, p. 34

%d bloggers like this: