Top ten security concepts that business managers need to know

Bookmark This (opens in new window)

Whether they know it or not, business managers are responsible for information systems, functions, and data within their span of responsibility. In order to effectively manage these assets, business managers need to be familiar with several concepts. Familiarity with these concepts will help business managers better understand the implications of their decisions regarding their employers’ assets.

Some material excerpted from Biometrics For Dummies by Peter Gregory and Mike Simon.

Defense in depth

This concept specifies that two or more controls, ideally of different types, work in combination to protect assets. Each control provides some type of protection by itself, and together they offer greater protection. Examples of defense in depth include:

  • Castle. The ancients understood defense in depth and got it right. A loot of treasure or a beautiful princess are hidden in the innermost chambers of a castle that is protected by a moat, a moat monster (or possibly just a deterrent control in the form of a “Beware of moat monster” sign), a drawbridge, turrets for archers, high walls that are difficult to climb, inner courtyards with more gates, turrets, hostile terrain and so forth.
  • E-commerce data. An online merchant protects its valuable transaction data with firewalls, routers with ACLs, intrusion detection systems, system-level access controls, database-level access controls, acceptable use policies, audit logging, and encryption. Notice that some of these controls are preventive, while others are detective, deterrent, and administrative.

Least privilege

This concept states that personnel are to have only the permissions and authority that they require in order to perform their stated functions, and no more.

Least privilege applies equally to systems: programs, processes, and other objects should have access to only the data and other systems required. For example, applications should never be run as root or Administrator.

Fail open / Fail closed

Sometimes these mechanisms can fail, and when they do, they fail in one of two ways, which are:

  • Fail open. When a control fails open, this means that all events (authorized as well as unauthorized) are permitted. An example of a fail-open situation is the failure of a key-card or biometric-controlled door buzzer, resulting in a door that opens just by pushing on it. A fail open situation puts protected assets at risk because they can be accessed by any party.
  • Fail closed. In a fail closed situation, all events are blocked, including those that should be allowed. An example of a fail-closed situation is a failure of a key-card or biometric reader that prevents everyone from going through a protected doorway. A fail-closed situation disrupts business operations by preventing subjects from being able to access business assets or information needed to complete tasks.

Role based access control

In complex systems with many users, it can be tedious and time consuming to administer the access levels and privileges that individual users need. Many complex applications support the use of roles – abstract definitions or templates of predefined roles for common job descriptions. It works like this: an organization defines permissions for each role, and then assigns personnel to a role based upon their job title.

When changing business conditions require that people in a certain role have different privileges, only the role is changed, which results in the permissions for everyone assigned to the role being changed likewise. This is a far more scalable solution than administering permissions for each user.


Spoofing, in its most basic form, is the act of pretending to be something you’re not. There are many forms of spoofing, including:

  • Phishing. Those e-mails that pretend to originate from a financial institution or other organization that advises the recipient to “log in” to reset their credentials.
  • Spam. Often the vector for spreading malware (viruses, worms, and Trojan horses), spam messages often claim to be something they’re not.
  • Caller-ID spoofing. Several caller-id spoofing services provide a service that allows a caller to change their originating caller-ID number to any legitimate number.


At the most basic level, biometric systems need to be protected in three ways: confidentiality, integrity, and availability. Security professionals use the term CIA to denote these terms. Let’s look at these concepts more closely:

  • Confidentiality. Information must be protected from viewing by unauthorized parties and systems. While in many cases the biometric system is serving as part of the means to protect information in the organization, the biometric-related information itself must be protected from onlookers.
  • Integrity. The integrity of biometric-related devices, systems, and information must be maintained. All of the components in a biometric system must be protected from unauthorized tampering. This includes the biometric devices themselves, as well as the systems and software that make it all work. Any unauthorized modifications to a biometric system may render it ineffective.
  • Availability. The biometric system must be available for use at all times. If some condition or event makes the biometric system unavailable, then the assets that the biometric system protects may themselves be unavailable when they are needed. This could result in disruptions to business operations.

Social engineering

Clever and resourceful intruders know that the easiest way to reach a target is by the path of least resistance. If an intruder is unable to successfully penetrate the technical defenses of a system or facility, he may instead rely on some unwitting employee to help the intruder gain access. Some examples of social engineering include:

  • Tailgating. If an intruder is unable to enter a facility on his own, he can pretend to be an employee who has lost his key card (or index finger or eye) and follow an employee through a secured door. It’s especially effective if the intruder is carrying some heavy object like a computer monitor or box of books – an employee is more apt to help the intruder into the building.
  • Remote access. A clever intruder can make a series of phone calls to various people inside of an organization to get all of the pieces necessary to successfully log on to the corporate network. He can get the VPN URL from one employee, a user name from another, and get a password reset from the helpdesk if they do not sufficiently validate the identity of the “user”.
  • Loading Dock Entry. Many reasonably secure facilities will have a blind-spot when it comes to the loading dock. A good social engineer in a brown shirt and pants can often just walk in the back door with nothing but a clipboard.
  • Road Apple. The attacker leaves removable media lying around somewhere that it will get picked up, say near the door to the lobby. A curious employee picks up the media, takes it inside and plugs it in, whereupon it autoexecutes a Trojan or virus, granting the attacker access. This is especially effective if the media is of some value like a USB stick or an SD card.
  • Dumpster diving. Intruders can go through an organization’s trash in the hopes of finding discarded printouts, memos, and documents that contain enough information to con their way into a system or facility.

Change management

The number one cause of business interruptions, outages, and downtime is not technology, but people – people who make changes without fully understanding the implications of the change. Change management is the formal process of vetting every proposed change in a system prior to making the change. The steps in a change management process typically are:

1. Proposed change. Someone requests a change be made to a system. This change could be something as simple as a configuration change or as complicated as a software or operating system upgrade. The requested change should include: a) Description of the change; b) Business or operational justification for the change; c) Who will perform the change; d) When the change will be made; e) Impact of not doing the change; f) Risks associated with making the change; g) Backout plan in case the change is unsuccessful; h) Anticipated user impact (e.g. downtime while the change is made); i) Other systems affected by the change; j) Test results (hopefully the change was tested on a test environment).

2. Change review. The proposed change is circulated for review among all of the formal participants in the change management process.

3. Change approval. Participants in the process discuss the proposed changes in order to identify any other risks or impacts. Then they can decide whether the change can take place as-planned.

4. Change wrap-up. After the change is made, final recordkeeping can be filed, to record the successful implementation of the change.

Access management

Organizations with information systems and information assets accomplish tasks and meet business objectives through people. People access these information systems and assets to directly or indirectly manage or perform these tasks. People require access to the right functions and systems in order to accomplish this.

One of the leading causes of security breaches is the “inside job” – where someone with access to a system causes deliberate harm. Often this is done by persons who have left the organization but whose access rights are still active.

Access management is a formal discipline and process where all access requests to systems are managed. The process of requesting and granting access should follow these steps:

1. Formal request. An employee’s manager should make a formal access request that states explicitly what systems, functions, or information the employee should be able to access and perform.

2. Review. The system or information owner should review the request.

3. Approval. The system or information owner should approve the request if it is determined that the employee does require this access in order to perform his or her duties.

4. Fulfillment. The access administrator (who is a different person than the requestor, the manager, the approver, or the user) fulfills the access request.

5. Recordkeeping. The request, review, approval, and fulfillment are all recorded in an official log.

6. Audit. Periodically (every month to every six months), the access rights of all information systems must be reviewed to make sure that all persons who have access are still authorized to do so.

7. Termination. Whenever an employee leaves the organization, all access rights must be terminated within 24 hours – or sooner for highly sensitive applications and data.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.