Skip Navigation
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10
Table of Contents Glossary of Terms
    CHAPTER 7
Protecting Your System:
Software Security
 
 
Illustration of the Cover of Safeguarding Your Technology
   
CHAPTER 7 IN A NUTSHELL:

Introduction to Software Security
Commonly Asked Questions
Policy Issues
Software Security Countermeasures
Software Security Checklist


 
   
Introduction to Software Security

Saying that software is an integral part of your computer system is like saying that the steering wheel is an integral part of an automobile. It's an understatement if ever there was one. All the technological and mechanical muscle in the world is virtually useless without a way of controlling it--and software is precisely the means by which users control what they are doing on a computer system. Application software affects all areas of computing. It defines the concepts of word processing and spreadsheets, and allows for e-mail and other forms of electronic communication that have recently become so prevalent. Its security, therefore, is essential to the overall security of your information and system.

    back to topback to home page

Commonly Asked Questions
   
Commonly Asked Questions

Q.Doesn't software come with its own security?
A. At some level, the answer is yes. Many types of software include security components within their programming, but, generally speaking, these safeguards are of a fairly simple nature. In most cases, they can be circumvented easily by skilled intruders. Effective software security requires a host of well-conceived policies aimed at software procurement, development, and use that must be realized through staff activity and organizational commitment.

Q.Isn't software security starting to get too technical for policy-makers?
A. Not necessarily. Effective software security can demand technical knowledge and experience, but policy-makers can overcome these concerns by including technical support staff in the policy development process.

Q. How can an organization overcome programming errors and viruses?
A. Any new or modified software has the potential to have programming errors. In fact, errors are a normal part of the product refinement process. Viruses, while not a normal part of any healthy process, have also become far from uncommon. But a rigorous pre-implementation testing routine (developed in coordination with technical staff) can diagnose these problems before they damage the organization's system or information. It is imperative that such testing be done on dedicated computers that are not connected to the organization's network and with dummy data in order to minimize risk.

   

back to topback to home page



Because certain aspects of software security can become quite technical, administrators should work closely with technical staff throughout the policy-development process.

 
Policy Issues

Because certain aspects of software security can become quite technical, administrators should work closely with technical staff throughout the policy-development process. Software security requires policies on software management, acquisition and development, and pre-implementation training. Unlike many personnel aspects of system security, appropriate software use requires that products and equipment match in a range of technical specifications. Policy-makers may, therefore, choose to pay close attention to the advice of technical staff when considering software issues and generating policy. Software users (virtually anyone who turns on a computer) should also be surveyed about the types of software required to perform their jobs, the ways in which those pieces of software are used, and the kinds and amount of training that are necessary to properly prepare staff to meet their job requirements.


As discussed more completely in Chapter2, a threat is any action, actor, or event that contributes to risk



 

Software Threats (Examples)

Examples of Software threats include:
  • Natural events (e.g., aging and dirty media)
  • Intentional acts of destruction (e.g., hacking, creation of computer viruses, and copyright infringement)
  • Unintentionally destructive acts (e.g., accidental downloading of computer viruses, losing instructions, and programming errors)
      back to topback to home page

A countermeasure is a strp planned and taken in opposition to another act or potential act.

 
Software Security Countermeasures

The following countermeasures address software security concerns that could affect your site(s). These strategies are recommended when risk assessment identifies or confirms the need to counter potential breaches in the security of your software system.

excerpt icon
  Countermeasures come in a variety of sizes, shapes, and levels of complexity. This document endeavors to describe a range of strategies that are potentially applicable to life in education organizations. To maintain this focus, those countermeasures that are unlikely to be applied in education organizations are not included here. If after your risk assessment, for example, your security team determines that your organization requires high-end countermeasures like retinal scanners or voice analyzers, you will need to refer to other security references and perhaps hire a technical consultant.
                          something you should do (icon)


Select only those countermeasures that meet perceived needs as identified during the risk assessment and that support security policy.
 




Test backup files periodically to ensure that they "restore" properly.

  Coordinate (and Centralize) the Organization's Software Management:
  • Centrally control all critical system software: (1) Know what programs are being added, deleted, and changed in your system; (2) control all additions, deletions, and modifications; and (3) take all necessary steps to ensure that new and old software work together appropriately (i.e., that they interface).

  • Initiate formal testing and certification procedures for new/modified software: Require that any new or modified software be tested rigorously and certified as fully operational before releasing it for general use.

  • Maintain an off-site location for critical backup copies (see Chapter 6): Backups of any and all software, databases, and information that serve critical functions should reside in a secure off-site location and be readily accessible when and if needed. Backups require the same level of protection as master files (i.e., if the files are designated as confidential, treat the backups as confidential as well). Periodically check that the backups function as expected so that there are no surprises if and when they are really needed.

  • Secure master copies of software and associated documentation: If master copies and/or their instructions are lost, an entire system can be put in jeopardy. But while documentation must be protected, it must also be kept available to users who have legitimate questions about proper use of the software.

  • Never lend or give proprietary software to unlicensed users: By definition, proprietary software means that it isn't yours to give--someone else makes their living by selling it.
   

It Really Happens!

Every state education agency has its computer whiz--that person who not only can program in seven different languages, but can also fix everyone else's system whenever and whatever problems arise. Martin was his agency's sensation. He was a programmer by training, but had so mastered system technology that it was eventually understood that he should be "doing his own thing." He was always working on some kind of new program or another that would inevitably revolutionize the way the state managed its data. Whenever there was need for a special computer job, there was little question where folks could turn.

But one afternoon Martin and the state superintendent found out that even the computer genius wasn't perfect. It seems that Martin's hard drive had crashed that morning as he was putting the finishing touches on a project that was needed by his boss that very day. Martin's initial response was to tell the superintendent not to panic, "Don't worry, I'm not foolish enough to go to all this effort and not back up my work files." But when Martin tried to access the backup files on another computer, he got nothing but error messages. It was then that he remembered that the files had all been created with the new software he had purchased especially for the superintendent's project. He also remembered that since he was the only one using the software, he hadn't loaded it on to anyone else's machine but his own.

Now panicked himself, Martin looked feverishly for the software's master diskettes. He checked the stacks of stray disks and piles of loose paper that littered his office. He went through every hanging folder in his filing cabinet. Where could those disks be? In a last ditch effort, he even called the local computer store to see if they could help. They politely told him that he'd have to repurchase the software unless he could produce a valid user license number--which could be found on the packaging of the master diskettes. That wasn't any help.

In the end, Martin didn't get the project to the superintendent on time. He eventually found the master diskettes at his home (where he had taken all of the documentation to read one night several weeks earlier). But because he had been accessing the electronic HELP file through the software as soon as it had been loaded onto his computer, he had never again thought about the paper documentation or the master diskettes. It was a tough lesson to learn--and it cost him some of the confidence he had worked so hard to earn from his boss.


read closely! (icon)  
  • Tolerate nothing but licensed and organizationally approved software on workplace equipment: Games are fun and software from home can sometimes be useful, but they have no place on organizational equipment unless explicitly authorized.

  • Monitor software use (and hard drive inventories) to counter possible copyright infringements: Unlicensed software on organizational equipment puts the entire organization at risk for fines and other penalties stemming from copyright violations. Software inventories should include the name of the manufacturer, version number, assigned computer (as applicable), and function.

  • Permit only authorized personnel to install software: In this way you know exactly what software is being introduced to your system and that it is being installed properly.

  • Train staff on software use and security policies: The best designed software for accessing and manipulating information is useless if staff are unable to use it properly.



                           something you should do (icon)

Software acquisition and development is addressed in greater detail in another National Center for Education Statistics publication, Technology @ Your Fingertips (see Appendix C).


                        read closely! (icon)
  Regulate Software Acquisition and Development: 22
  • Define security needs before purchasing or developing new software: After identifying your needs through a risk assessment (see Chapter 2), the findings should be used as the criteria by which you select appropriate software products.

  • Require written authorization before anyone tampers with software: Any changes to software requires a paper trail of what, why, and under whose auspices software was modified.

  • Conduct design reviews throughout the development process: Continued feedback from expected users during development ensures that the product will satisfy functional specifications and security requirements.

  • Modify archived copies of software (not the copy that is up and running on the system): By doing so, you can be sure that you are not putting active applications and files at risk. Once the modified copy passes testing and is certified as operational, then and only then should it be loaded onto the system for use with "live" data.

  • Require that all software developed or modified by a programmer be reviewed by a second, independent programmer: This review should verify that all code is appropriate and correct.

  • Maintain master files of all developed software independent of the programmer: Software belongs to the organization, not the programmer. By controlling all original copies, the organization clearly guarantees this ownership.

  • Require documentation for all new or revised programming: Requisite documentation includes the name of the developer, the name of the programming language, the development date, the revision number, and the location of the master copy (i.e., the source code).

  • Verify authenticity of public programs: If software downloaded from the Internet must be used with sensitive information, be sure that it has not been tampered with by checking for a digital signature to verify its authenticity.
 


While the vast majority of staff are probably completely trustworthy, they are not impervious to accidents or other events that could keep them from showing up for work some day. The organization is entitled to, and should, keep updated copies of everyone's work files.

 

It Really Happens!

The management team had finally had enough of Lou the programmer. They might have been able to over-look his daily late arrivals and early departures (rumor had that even the airlines kept to their schedules better than Lou), but when he started his own computer consulting business on district time, they'd had enough. As his direct supervisor, Charlotte accepted the responsibility of informing Lou that he was being dismissed.

Charlotte and the Director of Personnel called Lou to the conference room to break the news. "Lou," Charlotte began, "you recall that six months ago the three of us met to discuss your work patterns. We informed you that they were unsatisfactory and that things would need to change. At that time you agreed to try to improve your performance. Unfortunately, it has become clear through this whole business of you leaving work during office hours to attend to your personal consulting that your performance has not improved. Therefore, I must inform you that your contract is being terminated."

Lou paused to assimilate Charlotte's message. "You mean that you're firing me?"

"Yes," Charlotte replied, "you are being terminated."

"Nah," Lou protested, "you don't want to do that."

Charlotte was surprised by his audacity, "Yes, we do."

"No," Lou clarified, "I mean you really don't want to do that. I've been working on the programming for the School Report Cards for the last six months. You need it if you are to have any chance of getting them out this year. It really would be a mistake to get rid of me at this point."

"Are you threatening to withhold work that we've already paid you for?" the Director of Personnel interjected.

Lou sensed the trap. "No, not at all. I'd never do that. But I can tell you that I've had a tough time keeping things organized on my hard drive, so I've had to store a lot of my programs on diskettes. Suddenly I'm having difficulty remembering where I've put them all. And if I'm having problems figuring it all out, I seriously doubt that you'd ever be able to find those files if you hired someone to replace me."

Charlotte paraphrased the effective, if thinly veiled, threat. "So, you're saying that we have a choice between keeping you or saying goodbye to the School Report Cards?"

Lou smiled smugly, "You said it, not me... but I like the way you think. Now, maybe it's time that we talk about a raise."

excerpt icon
 
Because new products are bound to have their share of kinks, software's "cutting edge" is often referred to only half-jokingly as its "bleeding edge." Bleeding edge software should be avoided for mission-critical activities.


something you should do (icon)
  Thoroughly Test Newly Acquired and Developed Software:
  • Specifically search for common types of computer viruses: Have technical staff check for common viruses such as Trojan Horses and worms.

  • Verify that all software user functions are working properly before putting the software into operation: Check that new software meets anticipated user needs, current system requirements, and all organizational security standards. This recommendation is also applicable when upgrading software.

  • Back up old files before installing new software and software upgrades: Don't risk the latest copies of your files/records until you're certain that your new versions are up and running properly.

  • Never test application software with "live" data: Don't risk losing real information if the software doesn't pass the test. Instead, verify software integrity with dummy files and/or copies of non-sensitive files.

  • Test on independent machines: Initial software testing should never occur on computers that are connected to the system. By maintaining a separate test environment, the entire system is not at risk if the software malfunctions.

  • Run existing and upgraded versions of software in parallel during final testing phases: By running the old software at the same time as the new and improved software, you can verify that the new versions generate the same or better results than the existing system.
   
Avoid the "ohnosecond"--that fraction of a second in which computer users realixe that they have just made a huge mistake with their data.

--adapted from The Electronic Traveller by Elizabeth P. Crowe

    back to topback to home page
quote-(Benjamin Franklin)   Software Security Checklist

While it may be tempting to simply refer to the following checklist as your security plan, to do so would limit the effectiveness of the recom-mendations. They are most useful when initiated as part of a larger plan to develop and implement security policy within and throughout an organization. Other chapters in this document also address ways to customize policy to your organization's specific needs--a concept that should not be ignored if you want to maximize the effectiveness of any given guideline.

   
Security Checklist for Chapter 7
The brevity of a checklist can be helpful, but it in no way makes up for the detail of the text.
   
Check Points
for Software Security
Coordinate (and Centralize) Software Management      Click here
  1. Is critical system software controlled by central administration?
     Click here
  1. Has a formal testing and certification procedure for new/modified software been developed and initiated?
     Click here
  1. Are backups of critical software and information maintained in secure facilities at an off-site location?
     Click here
  1. Have all master copies of software been properly secured?
     Click here
  1. Has all software documentation been secured appropriately?
     Click here
  1. Does the organization expressly forbid lending or giving proprietary software to unlicensed users?
     Click here
  1. Does workplace equipment store and use only licensed and organizationally-approved software?
     Click here
  1. Are software use and hard drive inventories monitored for copyright violations?
     Click here
  1. Is installation of software limited to authorized personnel?
     Click here
  1. Are staff adequately trained in software use and security?
     Click here
Regulate Software Acquisition and Development      Click here
  1. Are risk assessment findings considered before purchasing and developing new software?
     Click here
  1. Is written authorization required before any software is modified?
     Click here
  1. Is software design reviewed throughout the development process?
     Click here
  1. Are active applications and files (i.e., those actively running on the system) properly shielded from experimental/developmental software?
     Click here
  1. Is all software that is created or modified by a programmer subjected to review by a second programmer?
     Click here
  1. Are all master copies of internally developed software maintained by the organization and not the programmer?
     Click here
  1. Is suitable documentation prepared for all newly developed software?
     Click here
  1. Has all public software accessed via the Internet been verified for authenticity?
     Click here
Thoroughly Test Newly Acquired and Developed Software      Click here
  1. Are common types of viruses searched for specifically during new software testing?
     Click here
  1. Have all user functions been verified before new software is put into operation?
     Click here
  1. Are all files backed up before installing and upgrading software?
     Click here
  1. Are "live" data protected from new application testing?
     Click here
  1. Is new application testing done on non-networked computers?
     Click here
  1. Has old and new software been run in parallel to compare results?
     Click here
     

back to topback to home page
back to previous chapternext chapter