Internal Forces the Cause of Lost Data?

3 05 2010

Last week, I blogged about Accenture’s new report, “How Global Organizations Approach the Challenge of Protecting Personal Data,” and focused on their first finding, “there is a notable difference between organizations’ intentions regarding data privacy and how they actually protect it, creating an uneven trust landscape.” This week, let’s look at the second key finding:

“A majority of organizations have lost sensitive personal information, and among these organizations, the biggest causes are internal and therefore something they could potentially control. This suggests accountability for and ownership of how sensitive data is used may be lacking in many organizations.” The report goes on state that, “larger organizations struggle more to prevent breaches than smaller ones – likely because, with many more employees and more geographically dispersed operations, the opportunities for data to be lost or compromised is greater.”

The report found that 70 percent of organizations with more than 75,000 employees have experienced a loss of sensitive personal information compared to 40 percent of organizations with fewer than 500 people. Internal issues – employees (48 percent) and business or system failure (57 percent) – were cited most often the source of data breaches – a stark contrast to the common perception that external forces are the biggest threats to security and privacy.  Reasons for internal causes of data loss?

  • Lack of adequate policies and training programs
  • Lack of adequate controls – employees have too much access to sensitive data
  • Not having a full understanding of data flows across the organization

From an employee standpoint, there are simple measures that can be taken to ensure sensitive, proprietary or confidential information is not compromised. By giving employees an easy-to-use tool to encrypt and protect data, you are one step ahead of the game.

For larger organizations, the task can be more complicated. A large data center may have various protocols for sending information both internally and externally: FTP, SFTP, home-grown solutions just to name a few. Many large organizations might not even be aware of all the protocols used to transfer data. This causes silos of information and a general lack of secure file transfer. Solutions do exist to securely transfer data and files enterprise-wide, while setting up user authentication, controls and policies.

Do you have internal policies or controls set up to ensure the security of your data?


Is the IBM i secure or irrelevant? 16 bit pointers

31 12 2009

In my previous post, I pointed out that the internet is the most complex system in existence. I also promised insight regarding security issues relating systems attached to the internet. Although the first and most important way to prevent security breaches is to keep your system patches, PTFs, fixes, etc. up to date, the subject of this post is IBM i (i/OS).

I see a lot of articles and discussions about whether IBM i is really secure or just so old that it’s really irrelevant. In point of fact, it’s very difficult to find any hard information explaining the how or why of IBM i security or lack thereof. To treat the subject fairly requires a book, so I will only address one small aspect of IBM i security today – 16 bit pointers.

First, 16 bit pointers have what’s called tags associated with them. That makes the pointers actually 18 bits with two bits that only the kernel (System Licensed Internal Code) can access. If these pointers are changed outside of a kernel operation, one or both of the tag bits get reset which invalidates the pointer. Although it’s not apparent to high level languages, the system is designed so that all information, on disk or in main storage, is accessed via these pointers. As a result, all information is addressed as though residing in main storage; hence, the term single level storage.

The system also organizes storage and uses the pointers in such a way that a program cannot go outside of the bounds of its assigned storage without causing a system exception. In addition, no program, procedure or data object – files, data spaces, queues, etc. – gets accessed without full kernel validation using these pointers. This validation includes access, operation and management rights verification against the user profile whose authority rights are being used to access the object. To protect the system against outside manipulation, certain system critical objects, including user profiles, cannot exist outside of the system Auxiliary Storage Pool.

Due to the design of these pointers and their use by the kernel, a worm or virus cannot take control of a program and trash or corrupt the kernel or access unauthorized information so long as the system runs at security level 40 or above. More about security levels at another time.

This only touches on one aspect of IBM i security. However, the security of the most security capable system in the world depends on
1. The competency of the system administrators
2. Limiting user authorities to only those needed to perform the required jobs and
3. Properly securing assets including passwords.

To dig deeper into aspects of pointers and IBM i internals, read the following. Some of the articles are outdated but still contain important information. Also, some of the articles contain specific information that enhances understanding of IBM i in addition to repeated information from other articles.

Notes for Storage Research by David McKenzie

AS/400 Memory Management from Inside the AS/400 by Frank G. Soltis

Architecture of the IBM AS/400 by Vincent LeVeque at James Madison University, document CS511 dated March 2001

An Object-based Systems Architecture from Smalltalk Musings by Richard Demers

Use the MI to Work with Pointers in ILE RPG by Junlei Li in MC Press Online

The AS/400’s Architecture Goes Beyond Technology by Frank G. Soltis via SystemiNetwork

OS/400 Storage Management from the IBM Information Center

Materialize Pointer (MATPTR) from the IBM Information Center

Resolve System Pointer (RSLVSP) from the IBM Information Center