- Securing the Organization: Equipment and Access
- Managing the Availability and Integrity of Operations
- Implementing New Software and Privacy Concerns
- Regulating Interactivity Through Information and Equipment Control
- Mobilizing the Human Element: Creating a Secure Culture
- Creating Guidelines Through the Establishment of Procedural Requirements
- Determining Rules and Defining Compliance
- Securing the Future: Business Continuity Planning
- Ensuring a Successful Security Policy Approach
- Surveying IT Management
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing New Software and Privacy Concerns
This section addresses issues to be considered when implementing both custom and vendor-supplied software, and the integrity of data during transmission. The discussion centers on the following topics:
Custom and vendor-supplied software
Sending data: privacy and encryption considerations
Custom and Vendor-Supplied Software
The task of determining appropriate software for a company network can be challenging. Many organizations have invested untold sums assigning internal teams to test a litany of vendor offerings, only to decide that no single product could meet their unique requirements; the organizations were then relegated to writing their software. It's an expensive process that can be fraught with its own set of potential security issues.
Regardless of the route an organization might follow—in-house, custom-written software or off-the-shelf vendor-supplied software—certain fundamentals must be met. For example, extended password protection might not be of interest today, but in the future, unforeseen circumstances could force an organization to change its security posture. It is prudent to ensure that basic privacy options are included in current software and can be implemented without necessitating wholesale structural changes.
Custom programs should include the following items:
During the development stage, creating a program that identifies potential security holes and implements an effective process to plug them
Prior to production, running acceptance testing to root out unforeseen programming errors
Postproduction, initiating a process that continually searches for newly created holes, and plugs them
If an organization plans to use off-the-shelf software, it is best to select a program that requires the least amount of modification. Well-known brands should have most holes plugged before the product is released to market, but by virtue of their brand-name status, these products can also attract more attention than lesser-known brands; this can result in hackers searching for holes even more diligently. In instances where issues surface after the product has a widely installed customer base, manufacturers are typically quick to issue patches to correct problems.
Postinstallation software modifications could potentially create back doors, because changes never occur in a vacuum. In typical situations, one change usually begets another, and the computing world is not immune to the domino effect of changes. The less software is modified, the fewer unexpected and unforeseen changes will result.
Change Control
A process that documents all changes, regardless of how minor a particular change might seem, can help to counter a negative impact a change might pose to a system. Commonly known as change control, it is a process that allows organizations to retrace their steps, from approval and security assessment of the proposed change to system backup, implementation, and monitoring of the change. Should an issue ever result from the change, determining the source of the issue should be less challenging to ascertain.
Sending Data: Privacy and Encryption Considerations
An organization might not need to encrypt every communication it sends out. Adding steps to any process naturally slows a system, and while it can seem inconsequential, encrypting and decrypting a communication still requires time and effort for both the sender and receiver.
Organizations can dictate a practice to streamline file encryption by developing a policy that states which communications are to be protected. The approach might consider the sender or the type of file being communicated. For example, a rule might state that e-mails from the CEO or files from the finance department are automatically encrypted. Conversely, an organization might consider encrypting all data it sends out, regardless of importance, to avoid inadvertently singling out its most sensitive transmissions to hackers. When a process becomes policy, less chance exists for confidential data to inadvertently be communicated in clear text.
Similar to a corporation's automatic encryption of particular users' e-mails, a program should be established that ensures the safe handling of users' public keys and certificates. The program should also include a process that revokes the keys and certificates when they are no longer required.