Security Solutions

Mar 1, 1997 12:00 PM, By G.F. BRYANT JR.

Note: This column draws on the expertise of the World Institute for Security Enhancement (WISE), Greensboro, N.C., a non-profit organization offering education and consultation on safety, security, investigations and loss prevention. G.F. Bryant Jr., is executive director of the World Institute and president/CEO of Bryant and Associates, Greensboro, N.C.

Q What is the Year 2000 Bug we have been hearing about? Does the problem center primarily on software? How will it affect our access control/security systems computers and what can be done about it? Are mainframe computers the only ones affected or are personal computers also at risk?

A The countdown to the dawn of the next millennium is now at less than 1,000 days. On Saturday, January 1, 2000, you could be enjoying a pleasurable New Year's Day with family and friends or be feeling that Armageddon has prematurely arrived with you as its principal target. Which one you experience depends on how well you prepare for this potentially catastrophic event.

For decades, programmers have stored date information in a mm/dd/yy format to conserve computer memory and disk storage space. Programmers used computations that took the two-digit year into consideration when computing time periods and ending dates, representing years as two digits without consideration for what might happen in the year 2000. Adding two digits to a date field for a 100-million record file would have added at least 100 megabytes of storage requirement to a disk. At one time, the cost for 15-20 megabytes was more than $20,000. It made economic sense to lop offthe two digits that represented the century. Also, the system resources could gradually be affected by the additional stored information. They would eventually require additional memory or suffer sluggish performance.

Now, industry faces the problem of adding those two century digits back into the date field in order to keep software running and producing correct output. The problem, however, is not isolated to software. Hardware will also cause difficulties for systems administrators. Are mainframes and COBOL applications the only areas of concern? Absolutely, positively no! System clocks on virtually every personal computer (PC) will wind up with corrupted dates on January 1, 2000. In some cases, the date will appear to roll over to the correct date, but when the machine is turned off and then back on for the next session, the date will have changed to something odd, such as January 1, 1980; January 4, 1980; January 1, %000; or some other combination of characters, all of which will produce erroneous results.

The dilemma is not limited to mainframes and PCs. Some workstations, minicomputers, elevators and even automobile central computers will fall victim to the insidious problem. In some cases, software patches can alleviate the condition to a more or less livable extent. In other cases, the date issue can be resolved only by replacing the hardware as well. With software, the problem will be most visible in routines that sort with two-digit-year fields. Storing 1999 as 99 and 2000 as 00 will cause the 00 date fields to sort out before the 99 fields. The consequences of this action can be determined only after the context of its use is understood. Additional difficulties will crop up and already have in certain industries.

Security applications likely to be affected Experts estimate that up to 80 percent of all computers - nearly 100 million - will not be able to handle the new millennium. However, models based on assumptions about corporate PC usage suggest that only a few percent of off-the-shelf PC applications are likely to exhibit year 2000 problems.

While the risk seems small, access control/security systems applications have been historically proprietary in nature and are therefore more likely to be affected. Finding and correcting these applications can be time-consuming, disruptive to operations and expensive. Also, a vendor may choose not to upgrade a particular version of software but to replace it with a more current operating platform. Clients would be stuck with purchasing a newer, less desirable program requiring a lengthy learning curve and, perhaps, costly additional hardware. The alternative would be to change manufacturers altogether and begin from scratch, an option that is not very desirable when substantial investment has already been made. Besides, the computerized access control/security systems presently in use are finally providing the functionality originally advertised. It has taken years to get all the bugs worked out, and now you have to deal with the most widespread computer problem of the millennium!

Education is first step Education and training can significantly reduce this problem. Prevention will be the most cost-effective cure. Begin by initiating a plan of action; time is of the essence. A simple test will tell you if your PC is reliable. Set the date to December 31, 1999. Set the time to 23:58 hours and then shut off your PC. Wait five minutes, then turn the power back on. The date and time should show a few minutes past midnight on January 1, 2000. If your system has the wrong date, your software probably does too.

There are four key areas of risk to PCs: hardware, operating systems, programs and data.

* Hardware (moderate risk): PCs include read-only memory (ROM) software called BIOS, which is responsible for basic start-up functions and managing persistent data such as time and date. Some PC BIOS software does not correctly roll dates across the year 2000 boundary. Many of these faulty PCs will be retired by then, but some will remain. They can be easily identified, though the cost of finding, correcting or replacing them will be high.

* Operating systems (very low risk): Common PC operating systems, including DOS, Windows and OS/2, can correctly manage dates beyond the year 2000. * Programs (moderate risk): The number of programs developed and the diversity of the tools used by professionals and end-users present the greatest challenges. The characteristics of these software tools vary greatly, as does their vulnerability to the year 2000 problem.

Some examples: 3GLs such as C, C++, Basic, COBOL, PASCAL, and assembler; GUI and pre-GUI 4GLs; work group/work flow tools such as Notes; and desktop database tools such as Access, dBase, Paradox and Foxpro; end-user computing tools such as macro languages embedded in word processors and spreadsheets; and a wide range of utilities and desktop tools, many of which represent or compare dates. PC programmers often operate with weak standards and controls, and programmers in any language may create problems through poor coding practice. Some programmers and power users who are unaware of the year 2000 issues may be creating unsafe applications.

* Data (moderate risk): PC application data may be stored in an alarming number of file formats, some of which are proprietary. Most PC databases can be used safely in a year 2000 setting, but many existing schemes will use only two-digit date fields. Affected databases will be difficult to identify and expensive to convert.

Estimate extent of problem Foremost in deciding where to begin is estimating the extent of the problem. Contingency planning is essential. First, initiate a Year 2000 Project with management support for a multi-year process. The modular solutions process must be guided by a dedicated, full-time oversight staff. The project team should solicit additional representatives from affected departments. Primary responsibilities include an inventory of affected computers and vendor sources, and a determination of the number of affected lines of code. Establish a time frame for the project.

Most information technology projects fail. They cost more, take longer and deliver less than anticipated, or they just don't work. The issue must be addressed immediately with a policy on procurement. The lack of time will breed failure if you do not begin now! Shortcomings have historically been tolerated by management because they either do not understand the issues or are intimidated by the complexities. This is one deadline that cannot be taken for granted. The process is full-time, and the number of staff hours will only increase as the deadline approaches.

The problem is one of functionality, not technology. A Year 2000 Compliance Team should prioritize anticipated problem areas. The belief that every computer-related function can be brought into compliance within the time remaining is misguided. Categorize and devote efforts specifically to mission-critical functions: customer, employee (payroll), security and redundant functions (more than 20 percent of all computer functions are redundant by nature.)

The essential elements of a strategy for solving the year 2000 problem are: * performing an enterprise-wide assessment of the extent of the problem; * assessing infrastructure and additional requirements to support any new functions associated with the solution; * deploying strategies for solutions; * defining validation strategies for testing modifications and assessing the software's compliance to standards; and * detailing budgeting strategies.

Take a systematic approach For strategic compliance, the process of managing legacy applications and addressing the year 2000 date change involves the following:

Inventory: Understand the existing environment by identifying applications and the languages used to develop them. The inventory must include platform, database and operating system information. It must also identify and relate the functions and the users of applications.

Scope: Reconcile the time frame with the cost. The sooner you begin, the less the cost and time in staff hours. Business goals and critical systems must be the drivers for determining scope and priority. When using an outside vendor, it is important to identify how the vendor estimates. Request a detailed proposal and references.

Descriptor: The year 2000 date change is a result of data rationalization. Tools that perform this function can be easily tailored to focus on the date elements. Experience in using these tools and the provision of a template that focuses on date are the key criteria.

Examine: Determine the movement of the data elements and the resultant use and location of date-oriented calculations as well as the quality of the application.

Consider Options: There are three options when resolving year 2000 date-change scenarios. One option, best used for noncompetitive applications, is to replace the application with a package solution. Clients must ensure that the vendor has a year 2000 solution. A second option is to expand the date field to include a century indicator - the most complete solution and the most costly. The third option is to focus on the application only. Based on date characteristics, the appropriate century indicator is used in computations, with results tested for boundary values and accepted if within bounds. This is less costly and requires less system-level integration testing.

Tactical Solutions: Driven by time and cost factors, the total solution to the year 2000 date change will be varied. You must think strategically and understand how an application fits into the overall business plan. You must also act tactically and apply only the solution needed. Do not overreact or apply one solution to fit all scenarios.

The basis for this column was a compilation of information from various year 2000 sources. Further information may be obtained on the Internet at http://www.year2000.com or http://www.spgnet.com. For information on the Year 2000 Conference and Expo, scheduled for March 26-28, 1997, at the New York Hilton and Towers: 508-652-1010, fax 508-652-1200.

Want to use this article? Click here for options!
© 2012 Penton Media Inc.

This month in Access Control

• Targeting The Customer
• Electronic Pedigrees
• One Hero Among Many
• Who? What? When? Where? Why?
• More from September's issue