IT Security History and Architecture - Part 1

Wednesday, August 11, 2010

Dr. Steve Belovich


1.1 Recent Security Issues

The past year has witnessed an amazing number of articles, reports, seminars and news stories about successful hacking attempts and the lack of data and/or network security.  The GAO recently reported that:

“Despite indications that agencies have improved their compliance with parts of the Federal Information Security Management Act (FISMA), many major agencies still consider their information security controls a significant deficiency or material weakness” - GAO May 2009

Even “Mighty Google”  is not immune and is a target, as this article shows:

“Ever since Google disclosed in January (2010) that Internet intruders had stolen information from its computers, the exact nature and extent of the theft has been a closely guarded company secret. But a person with direct knowledge of the investigation now says that the losses included one of Google’s crown frakels, a password system that controls access by millions of users worldwide to almost all of the company’s Web services, including e-mail and business applications."

"The theft began with an instant message sent to a Google employee in China who was using Microsoft's Messenger program, according to the person with knowledge of the internal inquiry, who spoke on the condition that he not be identified."

"By clicking on a link and connecting to a “poisoned” Web site, the employee inadvertently permitted the intruders to gain access to his (or her) personal computer and then to the computers of a critical group of software developers at Google’s headquarters in Mountain View, Calif. Ultimately, the intruders were able to gain control of a software repository used by the development team.” - NY Times, April 19, 2010

A common thread that runs through these articles is the network.  Invariably, the focus is always on intrusion detection and how the network is configured.  Firewalls, anti-virus software and anti-spyware are front-and-center as are algorithms for identifying intrusions. 

Perimeter security has been the “accepted” defensive approach and the three main hacking steps of scanning, footprinting and enumeration are given little attention.  Also ignored are the vulnerabilities that are built-in to the TCP/IP protocol itself which permits challenge and response without authentication.

Scant attention is paid to the serious vulnerabilities of software assets, e.g., the source code base, “make” files, module management systems, libraries, etc. due to poorly-planned access mechanisms and deployment.  After all, hackers gained access to Google's code base through a web browser which, in retrospect, seems a huge oversight.

What is totally ignored in analyzing IT security issues is the fundamental engineering & architecture of the IT systems that were penetrated and what can - or should - be done about that. This is at the heart of the “security problem” and also represents a key rate-limiting step preventing much-needed advances in IT systems' operational capability.

Another problem is confusing IT system architecture and engineering with mere programming or coding.  Architecture and engineering refers to how and where information is acquired, archived,  analyzed, transformed, distributed and presented. 

Architecture and engineering also govern how information is protected and how access is granted, controlled and monitored.  Coding is merely a vehicle for doing that.

Given all this media attention, what else could be said about data/network/software security that has not already been said?  Well, actually, a lot. 

In the rush to point out the vulnerabilities, threats, exposures and liabilities scant attention has been given to the real fundamental issues:  1) what the “security problem” really is, 2) what caused it, 3) why you are not safe no matter how many “official NIST certifications” you may have and 4) what actions should you take.

1.2 What’s Really The “IT Security Problem”?

The “ITSP” (IT Security Problem) is a generic term for the problems that arise when trying to achieve a set of operation-related goals.  There are six members of that set:

1. IT systems should do exactly what they are intended to do
2. IT systems should operate when intended to do so
3. IT systems should work on behalf of duly-authorized personnel
4. IT systems should NEVER do what is NOT intended
5. IT systems should NEVER operate when NOT intended
6. IT systems should NEVER work on behalf of NON-authorized personnel

The ITSP is much more than a mere “network protection” issue.  That is a major reason why attempts to secure IT systems by merely securing the network via firewalls and intrusion detection schemes do not work very well – they only focus on the network and ignore everything else. 

It's also another reason why following every guideline and meeting various certifications will not make you invulnerable and may, in fact, leave you even more exposed because the root causes of IT system vulnerability are not addressed.

So, is this the real security problem?  Not entirely. 

The real security problem is bad software design,  poor implementation and the mass deployment of critical tasks onto fundamentally non-secure platforms.  Note that this problem has little to do with specific “software tools” or network designs. 

Rather, it deals with the deeper issues of how we engineer software, the qualifications of who engineers the software and how we select and deploy IT systems and software to run our organizations.

1.3 Why Understand The History of IT Security?

Understanding the history of IT security explains why we are in this situation of seemingly never-ending vulnerability to data theft, cyber attacks and hacking.  It also significantly impacts our “go-forward” options due to the inertia of installed base and existing infrastructures. 

Ignorance is always costly, so knowing the root cause(s) helps us prevent repeat errors and guides us to effective, long-term solutions.  If the problem is understood, a solution is possible.  Conversely, if the real problem is not understood, a real solution is impossible.  That's basically where we are right now.

Part Two Here

Possibly Related Articles:
Security Management DoD
Post Rating I Like this!
Rob Lewis A very thoughtful post Steve. I would say also that if the root problem is not understood, then it also may be impossible to recognize a solution when it is actually presented.

Looking forward to the rest.

Barry Schrager Well Steve,

I certainly know the history. I started in this area as Assistant Director of the Computer Center at the University of Illinois in Chicago. We had an IBM system with TSO (Time Sharing Option) in 1970. Students would figure out how to bypass the IBM system integrity and ask one of my employees, Eb Klemens, to press the Enter key. Then the system would crash!!! Eb learned to be be very hesitant about pressing Enter when asked. We reported the exposures to IBM.

Then in 1972, I was asked to form the SHARE Security Project to develop the requirements for future IBM Operating Systems. After much discussion, we determined that we could not proceed with data security without addressing operating system integrity.

Also, in 1972, Eldon Worley of IBM and I gave a presentation on what we thought the IBM Operating Systems should provide in the area of data security. Recently Eldon told me there were IBMers in the back of the room trying to determine whether data security was important to their customer base. Can you believe that?

At any rate, in 1973, IBM announced a committment to Operating System Integrity for its OS/VS2 (now called MVS and z/OS) Operating System. This is the basis of data security on mainframes -- you cannot have data security without system integrity. Although not perfect, this is a committment that other systems do not offer.

In 1976, IBM introduced its mainframe data security product (written by Eldon Worley) called RACF. At the time, although it does now, RACF did not meet the SHARE Data Security Project requirements and our IBM Representative told me that they could not figure out how to implement them.

Well, that caused me, along with Eb Klemens and Scott Krueger, to develop the ACF2 mainframe security product which met the requirements and has generated well over $1 billion in revenues. It is now owned by CA Technologies and is still used in many prestigious installations.

Another of my former employees, Ray Overby has been working on a product to investigate system integrity vulnerabilities in the z/OS Operating System, installed program products and installation developed operating system extensions and exits. Unfortunately, there are still some system integrity exposures in z/OS that we should be concerned about since they would allow a user to byass the controls of the installed security system, whether it be ACF2, RACF or Top Secret.

More information on Ray's work can be found at

Barry Schrager
Dr. Steve Belovich Great comments, gentlemen. Thanks too for the IBM history. There were a number of fundamental contributions to O/S security made by IBM, DEC and others during the 1960s and 1970s. Some highlights will be forthcoming in parts 3 and 4.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.