Network Defense by Richard Power and Rik Farrow Y2K efforts weaken security in numerous ways The Y2K crisis is looming closer. Everyone is scrambling. Well, hopeful= ly everyone is scrambling. What is your organization doing to get ready? M= aybe nothing, or very little so far. If so, you aren=92t alone. But even if = you are moving forward at a steady pace to avoid disruptions and other serious = problems at the turn of the century, there is one aspect of Y2K conversion that = is probably not being paid enough attention=97information security. To save you some time and spare you some grief, here are a few practica= l insights culled from information security experts working the Y2K issue= =2E Down the brain drain One of the big problems with Y2K is that it is consuming time and energ= y that would otherwise be spent hardening Web sites for electronic commerce an= d building adequate security into corporate intranets. Cheri Jacoby, CISSP, of Price Waterhouse enumerates some of the ways in= which Y2K will have a negative impact on information security initiatives. =93Y2K is definitely is draining resources (mind, money and muscle). Th= ere is a common thought that perhaps now is not the time to invest in new techno= logies=97 including security products. Furthermore, if you have your best and bri= ghtest helping you deal with the Y2K issues is there anyone minding the shop? Jacoby warns of underestimating the challenges. =93One challenge in regard to information security is to know how much = control is enough and how much control is too much. You don't want to make securit= y so restrictive that it is impossible to appropriately test and prepare for= Y2K=97but at the same time, you don't want to hand someone the key to your front = door. The other big Y2K challenge is that becoming dependent on contractors alway= s adds risk.=94 Y2K as information warfare Is there a threat from "subverted=94 Y2K code? According to Keith Allan Rhodes of the U.S. General Accouting Office (G= AO), the answer is =93yes.=94 =93The Y2K frenzy creates a new attack scenario, which, unfortunately, = is yet another symptom of the disease of poor security=97lack of discipline an= d rigor in security engineering. Normally, an adversary would perform an analysis = of the targeted organization's ability to protect its assets, detect break-ins= , and react to them. Now, with Y2K, the adversary gets to let the targeted organization's Y2K panic bring it to them=94 For example, you now realize you're in trouble with this =91Y2K thing,=92= and you identify your mission-critical systems. You realize you lack sufficien= t resources to fix the systems. You convince your money bosses that you c= an =91outsource=92 most of your processing and programming to a service pr= ovider. But many of the service providers are not taking any new clients=97they=92v= e got too much work already. Some others are taking new clients, but sending the = work off- shore (for example, India is becoming quite a software factory these da= ys). So where is your firm now? You have signed on with a trusted name and know= n quantity. But that firm has sent your outsourced processing and program= ming to a third party in a foreign country, which in turn has subcontracted it fu= rther (I have seen as many as seven levels of subcontracting). Now you have a mu= ch larger problem than Y2K=97which will only get worse as the deadline approaches= =2E Any common sense measures to stress in either prevention or detection o= f such subversion? Rhodes makes some suggestions. =93Do not allow Y2K to blind you to your normal development requiremen= ts. Remember that the systems you worry the most about are your most import= ant systems=97don't give them away, just because you're behind schedule! P= revention is going to be a function of how well you can know and watch and check= on the people doing the work. It's pretty hard to validate a background check = on someone in another country working for a sub-contractor. It is much ea= sier to watch someone who is in your facility, working with your people in you= r environment. And as far as detection, you have to have some form of independent vali= dation and verification=97someone has to independently check the test results = and the code. This is not either inexpensive or easy, but if you're going to op= en up your mission-critical systems, you better double check them. Also, star= t building your operational contingency plans now=97this is not just a =91= work around=92 for a particular system, this is a plan for your business continuity. = That way, if the worst case occurs, you will be able to salvage your operation. Stages of a Y2K compliance program Victor Blanchard of Coopers and Lybrand LLP identifies six distinct com= ponents for a Y2K conversion effort: p Awareness: Raise the awareness of senior management to the risks p Assessment: Initial determination of exposure and scope p Research and planning: Establish date representation and testing stan= dards p Conversion and testing: Convert and test all identified systems p Implementation: Implement all modified objects and files in productio= n p Monitoring: Monitor, identify and correct failures As Blanchard observed, each one of these different components raises so= me serious information security issues. During the initial awareness phase, Blanchard pointed out that manageme= nt needs to acknowledge, in addition to the date-related code changes, the impor= tance of=20 sustaining (minimally) appropriate information security controls throug= hout the=20 Y2K conversion. =93When you=92re in the awareness phase of a Y2K conversion, management= needs to acknowledge that information security doesn=92t take on any less releva= nce. If the approach is =91let=92s bring in a consultant, give them whatever they n= eed to correct this problem,=92 you may be opening yourself up to some signifi= cant information security issues. Organizations starting late may focus more= on accessibility than security.=94 Existing controls must be maintained. For example, adherence to existin= g policies and procedures, exercise of access controls to the operating = system, application and data, attention to the physical security to the data ce= nter.=20 Indeed, adherence to existing controls may not be sufficient=97addition= al policies and tighter access controls may also be needed Of course, another important question to ask is, =93Who=92s going to ow= n this project?=94 Assessment According to Blanchard, information security should be considered in th= e development of the preliminary resource schedules supporting the conver= sion effort=97for example, personnel, hardware and software and storage capa= city. Information security has to be brought up at the table, Blanchard expla= ins. If you come in later only because you=92ve identified information secur= ity concerns and issues after the Y2K conversion has begun, it=92s going to= be even more difficult to get the concerns addressed=97because you will not hav= e been budgeted and any time you spend on that will be a variance and manageme= nt=92s going to resist that. So getting involved in the scheduling process and= actually getting people responsible for information security on that resource sc= hedule is going to be critical. It is also important that any scanning tools being considered be review= ed in the light of information security concerns. Research and planning Configuration management and other aspects of establishing additional r= egions to conduct pilot projects should be coordinated with information security = in mind. =93Are the additional regions going to be subject to the same access co= ntrols, policies and procedures that the original regions were subject to. If y= ou=92re going to copy all the data and applications to another environment are = they going to be protected in the same manner?=94 Implications for data and application protection should be addressed at= this point. For example: What are the potential consequences of giving confi= dential or sensitive payroll and personnel data to the Y2K consultants and pote= ntially others who have access to the alternate region?=20 Furthermore, tests based on accelerating the system clock can present s= ecurity issues=97for example, validity of system and security logs. Conversion and testing As conversions get underway, Blanchard comments, issues surrounding per= vasive consultant access to sensitive data and application will arise. =93Because Y2K conversion is primarily being driven by the consultants,= you=92re going to have to deal with what access do they have and how are you go= ing to control that access.=94 He suggests that a significant reassessment of resource needs be conduc= ted at this juncture. Someone has to take responsibility and reassess the organization=92s re= source needs. You got to say, =91This is now a much bigger issue.=92 Once the = organization decides to give the entire project over to Consultant X, you have to ev= aluate the information security issues raised by the kind of sweeping access t= hat the consultant will probably expect to be granted. Another serious concern is the development of test data.=20 =93We don=92t see many Y2K consultants generating test data. We see the= m taking a copy of production data and moving it somewhere to perform their testin= g. What kind of protection or controls do I have over what those consultants ar= e accessing? Maybe it=92s payroll information, maybe you=92re creating fi= ve year forecasts, may-be it=92s something of greater significance to senior ma= nagement that not every consultant who walks through the door should have access= to.=94 And it may not always be consultants. You=92re also going to have your = own internal people working on Y2K. If the Y2K conversion team (including e= mployees) is granted pervasive access to a copy of payroll data for testing purpo= ses, can they scan it and pick up co-worker=92s salaries? During the conversion and testing phase, you should also insist, stress= ing the information security issues involved, that code changing tools must mee= t internal testing and control. Implementation Code changes can impact both test and production environment in unexpec= ted and potentially dangerous ways. =93The myriad of different types of code changes are going to effect al= l the different facets of your environment. For example, you=92re going to ha= ve changes to the operating system, you=92re even going to have impacts on the sec= urity software itself.=94 You should be prepared in the event that such code changes to the opera= ting system or any of the significant system causes a major system failure, = Often, as systems come back up after such failures, you get into access control i= ssues. During this phase, take care to ensure appropriate contingency plans ar= e in place. Monitoring Consider information security in regard to monitoring system resources = and access activity, which provides some unique challenges during Y2K conve= rsion process. Blanchard explains. =93Normally, you=92re looking for data corruption, system failure, secu= rity breaches, inappropriate access attempts, successful inappropriate acces= s. But there are some other areas that we=92re going to be concerned with duri= ng a Y2K conversion. For example, you=92ve probably established separate regions= to facilitate the code changing process=97monitoring activity between thos= e regions and the real production environment is going to be critical. =93It=92s also going to be a little more difficult to track some of thi= s activity depending upon how you set up the special accounts that you=92ve create= d for either the Y2K consultants or for your employees that are working on th= is engagement or this project. It=92s not unusual for the consultants to b= e given generic IDs. We=92ll get an ID called =93Coopers=94 and we=92ll be told= to change the password, Maybe you have a team of 20 people who have access to the sys= tem. But you don=92t know which of those Coopers people did what, all you know i= s that someone who had access to the generic ID engaged in some sort of activi= ty that generated an alarm. So it=92s going to be a little more difficult in so= me cases to determine who was involved with particular activity that you=92re monit= oring.=94 Criteria for judging Y2K consultants and services Clearly, for many organizations, one of most important elements in laun= ching a successful Y2K compliance program is choosing the right consultants to = bring in. In his presentation on =93Picking a Y2K Toolkit,=94=20 Robert Martin of Mitre Corp. provided criteria for judging the experien= ce, resources and methodologies of Y2K consultants. Experience: How long have they been in the information technology busin= ess? How long in the Y2K business? What application portfolios are they familiar= with? What customers have they worked with? Resources: How many staff are devoted to Y2K projects? What are their = =93tool=94 and testing capabilities? What alliances do they have other companies? = What is the corporation=92s financial history and future viability? Methodology: Do they have a standard methodology? How many times has it= been used? For what =93application=94 domain? Some issues and considerations Ken Vander Wal of Ernst and Young LLP outlines some specific issues and= considerations that should not be overlooked. =93You=92ll need to bridge files. You=92re going to have to bridge thin= gs between what=92s compliant and what=92s not. =93You=92ll need to maintain preconversion programs and data=97especial= ly if you=92re concerned about your historical data being accurate. =93You=92ll need to convert historical data. There are some IRS rulings= that you may find interesting. Talk to your tax people. Convert what you need to do = your business and then have a process ready to convert anything else you mig= ht need. Also, on the business continuity planning side, you=92ll need to have a= system that can convert the old data. =93You=92ll need to make sure you go all the way through your system an= d hit all the libraries=97source, executable, JCL, copy library. Try to convert every= thing you can! For example, in the glass house, you can=92t just worry about the = Cobol source code. If you convert your application, but not your JCL, the sys= tem may not run.=94 Other potential problems involve object with no source code and tape ma= nagement (specifically, retention and expiration dates and =93perm=94 file delet= ion). Vander Wal suggests some proactive steps. p Evaluate Year 2000 testing options at hot sites. p Challenge application inventory. p Update data center recovery plan. p Champion business unit recovery plan updates. p Compare Year 2000 Business Impact Analysis (BIA) to Business Co= ntinuity Plan (BCP) BIA. p Insure that backup site hardware and software are Year 2000 com= pliant. p Review licensing agreements. p Champion creation of Year 2000 contingency plan. p Get involved now! =