Securing Personal Computers

Criminals (and network adventurers) expend significant effort breaking into personal computers, because that is where the money (or power) is.  

Increase IT Productivity through Standardization

When you read the word "databases" you think DB2, Oracle, MySQL, DLI, All-in-1, MS-Access. You may also realize that Spreadsheets, E-mail, and other documents stored on individual PCs are in fact part of the corporate database.

Modern database systems have four common components:

1. Data Definitions (or "Schema"), which includes not only the storage and display attributes, but also relationships, such as foreign keys and value constraints.
2. Data Access Programs (or "Scripts"), which range from complex APIs usable only by sophisticated IT departments, to the program behind a simple icon on any desktop.
3. Data
4. Productivity Tools

The separation of data definitions from program code into data-dictionaries, or "schema repositories", occurred as an evolutionary "best practice". A related evolution formalized data access programs as Abstract Data Types (ADTs) and Access Program Interfaces (APIs). Data descriptors together with their APIs are now called Object Classes, and the data itself, together with its class-association, is called Object Instances.

In older ("legacy") applications the data-definitions, and in particular, data relationships are often hidden in program code, and not formalized in a data dictionary. In other words, for the IT organization the source code includes both schema and data. These are typically core applications that are irreplaceable. When managing their maintenance and development, you need to gather information about your schema and access programs. The quality of this information and the speed of the response to your query are critical to your management success.

An organization with older applications can evolve their management, and improve productivity. One key approach is to modernize this "IT database". You need Access Programs and Productivity Tools such as Source Version Control and maybe Business Rule Extractors, but you need another critical ingredient.

A major key to the performance of databases is the consistency of data definitions and the normalization of data. In the case of legacy code, however, the definitions include hundreds of different Computer Languages (multiple COBOL dialects, Java, C/C++, FTP Scripts, VB, a myriad configuration files, and components in older languages). They also include the services encoded by System Service APIs, that obviously vary radically from the Mainframe to UNIX, to VMS, to Wang VS, etc.

There are good evolutionary reasons for the diversity and complexity, which were created by a competitive effort to solve real business needs through innovation. There are also management costs and risks to this complexity, including higher skill-set requirements, and reduced IT throughput. This is the reason that as technologies mature, there is a strong market push towards standardization.

Third generation computer languages are a mature technology. True, certain ones have specific strengths over others, but for the vast majority of applications, there are no better options than COBOL and C/C++, which are not only the most common languages and skills, but also come with the best of breed development tools, and the best support on platforms, from Mainframes, to UNIX, to PCs.

How does one justify source code standardization? The best way is as part of other standardizations. If your IT Department is converting applications to a UNIX or an MS Windows network-based platform, older core applications that must make this transition will either use emulation or be converted. Conversion, particularly automated conversion using mature and proven cross-compiler technology, can be as low-risk as emulation, and is much more likely to have the added benefits of simplifying future maintenance, facilitating the next transition, and enabling those tools that will allow you to better manage your IT database.

Source Code Version Control Systems

Source code management ("SCM") is a requirement of all modern software maintenance and development efforts. This article identifies the requirements of the diverse functional stake holders. Several references are then given to free source code version control facilities.

Interested groups and their needs

The groups that have direct interest in the coordination and control of computer program maintenance and development, and their Program Source Code are the Business Users (Accounting, Sales, Production Control, etc.), Information Technology ("IT") Directors, IT Auditors, IT Installers ("Release Engineers"), Quality Assurance groups, IT Development Managers, and IT Individual Developers.

Production code is the fully tested executable programs serving day to day operations. The business users need to prevent unauthorized changes to production code.

IT Directors and Auditors need controlled Transparent processes and audit trails, as well as information for process improvement efforts.

Development managers need to coordinate staff to avoid conflicts and duplication of effort, manage resources and reassign tasks, log assigned staff and development start and progress dates for each module, and enforce consistent development directory names, shop-standards, and change submittal procedures.

Individual developers need a facilitated development submittal process, and archived versions for rollback and roll-forward. They may also need to lock sources that are needed for maintenance or development (or to identify who locked a requested source module).

QA groups need execute access to QA-ready programs, which are distinct from both Production programs and from programs under development. They also need facilities for rejecting programs found to be defective, and/or forward tested programs for release engineering.

Installers / release engineers need to enforce submittal procedures, archive change management data, and archive new modules or module changes, as appropriate. They also verify that all sub-components are available for rebuilds.

To summarize, source version controls need to prevent unauthorized Production Code changes, coordinate developers to avoid conflicts and effort duplication, log required change documentation for auditing and process improvement, and log source changes for rollback and roll-forward of changes.

Source Maintenance Cycle

This cycle historically starts with the development of new application programs, proceeds with their testing and QA, and concludes with their placement into Production use. However, once code is placed in Production use, the cycle becomes maintenance centered, and organizations with mature applications are mostly concerned with controls of the repair and enhancement of their existing code base.

Source Code Version Control facilities were developed to provide for all of the above requirements, and to enable IT groups that are charged with repair and enhancement tasks.

The basic steps of the maintenance and development cycle are:

• Check-out from the Source Repository to Development
• Submit from Development to QA
• Promote from QA to the Source Repository

• Cancel a check-out
• Reject from QA back to Development
• Roll-back to prior Source Repository version

Summary

The primary reason to automate the Source Code Version Control process is the desire to improve on both the consistency and the correctness of the IT Development results. The control facilities ensure correct operation by testing and handling a very large number of error conditions.

On UNIX and Linux systems there are four tiers of access controls and three levels of permissions, which protect directories (folders) and files. The control tiers are user-ownership, group-association, public access, and Access-Control-Lists (ACLs). The permissions for a directory are Read, Write, and Search. The permissions for a file are Read, Write, and Execute. In addition, a variety of tools are available to further control access, including Set User/Group ID bits, and access control utilities such as sudo and Power-Broker. These allow user and/or group-based controls to the Source Code Version Control facilities.

Here is more information on a few widely used Version Control facilities:

Korn Shell Tips

Parameter Validation

In some environments (e.g., WISP v4) the passage of parameters from COBOL programs may include leading and embedded spaces. Here is an annotated Korn Shell script header that eliminates such spaces. The script expects 2 parameters. Lines beginning with the pound/hash symbol (#) are comments.

set $* NoDump
if [ $# -ne 3 ]; then
  print -u2 "Usage: $0 FirstParm SecondParm"
  exit 1
fi

The first line re-establishes the incoming parameter list ($*), and adds one parameter (NoDump) to it. Any string of contiguous white-space in the incoming parameters is interpreted as a single separator space. This applies to leading, trailing, and embedded spaces.

A new parameter 'NoDump' is added to make sure that if no parameters are passed, or if the parameters passed are reduced to separator spaces, that the "set" command will not respond by listing the Environment.

The term '$#' is a count of the (reset) number of parameters. We added one, so comparison is to the expected number plus 1.

The 'print -u2' command directs its output to STDERR.

The term '$0' is a reference to this script.

The UNIX convention is RETURN-CODE 0 means SUCCESS. We use 'exit 1' to return an error condition.

How To Find Who Is Using A File

Some times you want to verify that no one is using your file before running a major update program. The lsof (List Open Files) command is Shareware/Freeware available for AIX, HPUX, Linux, and other environments. Two common ways it is used are:

    lsof $FILEPATH
    lsof -p $PID

The first line lists all the processes that access the file at $FILEPATH (e.g., ../execs/jjupdate.int or /client17/data/armaster). The second lists all files open by the Process ID '$PID' (e.g., 1776).

COBOL Tips