| |
|
CHAPTER 7
Protecting Your System:
Software Security |
|
 |
|
|
|
| |
|
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.
|
|
|
 
|
 |
|
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.
|
|
|
|
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)
|
|
| |
|
|
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.
|
|
|
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.
|
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.
|
|
 |
|
- 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.
|
Software acquisition and development is addressed in greater detail in another National Center for Education Statistics publication, Technology @ Your Fingertips (see Appendix C).
|
|
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."
|
|
|
|
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.
|
|
|
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 |
|
| |
|
|
 |
|
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
|
 |
- Is critical system software controlled by central administration?
|
|
- Has a formal testing and certification procedure for new/modified software been developed and initiated?
|
|
- Are backups of critical software and information maintained in secure facilities at an off-site location?
|
|
- Have all master copies of software been properly secured?
|
|
- Has all software documentation been secured appropriately?
|
|
- Does the organization expressly forbid lending or giving proprietary software to unlicensed users?
|
|
- Does workplace equipment store and use only licensed and organizationally-approved software?
|
|
- Are software use and hard drive inventories monitored for copyright violations?
|
|
- Is installation of software limited to authorized personnel?
|
|
- Are staff adequately trained in software use and security?
|
|
| Regulate Software Acquisition and Development
|
|
- Are risk assessment findings considered before purchasing and developing new software?
|
|
- Is written authorization required before any software is modified?
|
|
- Is software design reviewed throughout the development process?
|
|
- Are active applications and files (i.e., those actively running on the system) properly shielded from experimental/developmental software?
|
|
- Is all software that is created or modified by a programmer subjected to review by a second programmer?
|
|
- Are all master copies of internally developed software maintained by the organization and not the programmer?
|
|
-
Is suitable documentation prepared for all newly developed software?
|
|
- Has all public software accessed via the Internet been verified for authenticity?
|
|
| Thoroughly Test Newly Acquired and Developed Software
|
|
- Are common types of viruses searched for specifically during new software testing?
|
|
- Have all user functions been verified before new software is put into operation?
|
|
- Are all files backed up before installing and upgrading software?
|
|
- Are "live" data protected from new application testing?
|
|
- Is new application testing done on non-networked computers?
|
|
- Has old and new software been run in parallel to compare results?
|
|
|
|
| |
|
 
|
|
|
