T h e   A I X   S e c u r i t y   S u i t e

By Erik Kluit November 2002 Always busy, busy, busy ... you know the feeling? As an AIX guest instructor I must have past Michael Felt a hundred times in the last six years. Hardly time for a talk. But this time it was different. We started talking about security. The result of this conversation is this interview: giving you a glimps of who Michael Felt is, and of how some of the AIX Security courses are developed at IBM.  How did you get started in Security? Like many system administrators I got started from the technical side (what I now call mechanisms). However, my focus was not with hackers, but user and program errors. The so-called 'malicious' element came much later. How long have you been active with UNIX then? I got started with UNIX as a university student in 1979 - programming of course. My major was psychology, and as I started my masters in 1981 I started 'helping' the psychology department system administrator. I was the 'king in the land of the blind because I had one good eye ' - I knew UNIX, which was just being introduced to the department. Between 1981 and 1988 (my study tempo suffered from all the programming work) I built several embedded tools and libraries (now called API's I guess) as well as debugging existing and/or writing new UNIX (Berkeley) system drivers. For years I was focused on UNIX at the 'bit' level of interaction between applications, UNIX (system calls) and the hardware. I enjoyed it a lot, and it gave me insights into how UNIX reacts that I can still apply today.

Michael A.M. Felt is a certified AIX technical specialist (CATE) and the pSeries AIX Curriculum Owner in the Netherlands, based in Amsterdam. He has been with IBM for seven years with the role of educator, or knowledge transfer. Michael has many interests in the IT branch. Beside a masters degree in Cognitive Psychology on software ergonomy he has over 22 years experience with UNIX as systems developer, integrator and administrator. The last five years he has been involved in the design, development and/or review of IBM worldwide course material for communications, performance and security management. For security management he has been the leading designer of the new pSeries AIX Security Suite and an ‘eServer’ Security Overview.

Shall we try to get back to Security ...?

Sure. In 1996 I started working for IBM as an instructor. I was hired to teach the high-end courses for AIX - basically anything that an IBM customer might follow for AIX after having completing the advanced administration course. So, pretty much from day one I was teaching performance, tcpip, netview, and ... security.

IBM had just finished a new security course - or rather some UK consultants had just completed writing a new course for IBM - and I volunteered to host a TTT (train the trainer) session for the consultants to come and introduce the course to IBM instructors. This was March. By April I had taught the course twice and had very mixed results. The first group consisted of system administrators from various companies and a technical consultant. They loved the course and I had a lot of fun because I felt as if I had spent almost 17 years training for it. So much of it was just common sense IF you had the background in how all the different mechanisms interact with each other. "Leave this open means ... is open too. Closing this might make you think this is closed, but wave this wand, and ... is still open. And then demonstrate and explain why and how." And then the second group. They found the course interesting, but with one exception, not very useful. They were a very different profile: EDP auditors. And what they wanted was a model of security architecture applicable for UNIX, as well as a magic wand (i.e. a script) that could measure, or "certify/audit" the level of security on an AIX (read UNIX) system.

And this is where my new focus on Security (and probably much more) "started" - handling this customer complaint!

To deal with this complaint I committed myself to writing a two-day course for auditors. I thought it would be easy, but actually, it was very hard. Maybe the only project I have not brought to a personally satisfactory end. I was able to accomplish finding and writing up a model of security architecture that was suitable for UNIX - and more. But I was not able to satisfy their requirements for a security scanner. And in hindsight, it is easy to understand why. I didn't know their security requirements. And although I was not able to get this model of Security Management into IBM WW (world-wide) course material until this year I researched and taught a model of the security management PROCESS.

Can I interrupt for a moment? Until this year? That was 1996 - this is 2002. It took 6 years to get - well what actually did you get introduced, and why did it take so long?

To a certain extent, your question gives part of the answer. I have to begin my answer by saying - "I was lucky". I was at the right place at the right time. I was ready for a particular lesson in 1996, and others were less ready, and I could not express well enough why a model of security management was vital to security education. And to rephrase your question - let's focus on the first part - "what lesson?".

In 1996 I learned that as an instructor I could not be effective if I acted, or taught, as if I had the only answer, and the answer was always - more technical stuff, more technical skills. Over the years I have begun to realize that having more than just a technical focus may be the main difference between a "beginners" and an "advanced" course. Beginners and Advanced are not the correct labels - it is a scale actually. And I would label the scale - experience.

The lesson I learned was: as an instructor I need to be prepared to act as a guide, if not teach outright, at least one other perspective for looking at any problem. To simplify my preparations I choose two perspectives: the technical (of which I was already an expert) and the non-technical. And then my psychology training kicked in: process versus content (non-technical versus technical). Until 1996 I had "only" been asked to resolve technical failures - defects. And then the requirement is simple - "fix" it. The program is the "process", so fix the program (content), and the problem is resolved. So, the lesson is now: there are problems that are not defined primarily in technical terms.

The second part of your question: why it took so long - I suspect that, just as I didnt understand this overnight - for technical trainers who have lived in a world in which they have been trained to train that technology solves problems - it is not simple to adapt to a new way of teaching primarily technical material. This has not been easy to explain, and it requires a tremendous personal commitment by the instructor during his/her course preparation, or self-study. There is relatively little instructor material yet the knowedge domain is very large (vast actually).

I mentioned psychology. This was fortunate for me because this training gave me the "process versus content" theme that is used to help explain why people do not, or cannot communicate about a subject. They are using the same, or similar, words, but with very dissimiliar meanings or intentions. And security was full of this problem for me. Going back to 1996 - the right place and time - I had many discussions with this group of students, especially after I had taught my special two day course that I had written just for them - trying to understand why it had not addressed all their needs. In the end we helped each other realize that a course developed primarily to instruct technical people in order to increase their skills was not generally the best sort of course to follow for their more management oriented needs. And further, that their technical requirements (auditing a migration from one technical platform to another and expecting reports that were the same, or improved versions, of the original platform) were so unique to their environment that a general course could not be expected to address the majority of their technical needs either.

This is "what" I learned then - but more a seed was planted that needed time to grow. And after I felt I understood it well enough to convince others - they too needed time for it to grow.

When was this?

I guess about 1998 is when I started trying to converse with colleagues about this. By 2000 I was making headway, but security did not have the highest priority. AIX 5L was coming and we had to update a lot of standard, mainstream courses (it takes 6 months to a year to complete a major update - per course). There were not enough developers to work on it all. In the beginning of 2001 I wrote a whitepaper proposing the development of a Security Suite for AIX. And I was lucky. One project was downgraded - releasing development funds - and the Security Suite proposal was chosen to receive the funding!

Can you describe the Security Suite?

:) I certainly hope so! The security suite has as it's core two models: a model of security architecture and a model to manage security. I call the second model the "Security Management Cycle".

The first course in the suite is titled "eServer Security Overview" and not pSeries or UNIX Security Overview because these models are not limited to only the UNIX platform. In time, the course is expected to become THE introductory course to Security offered by IBM Learning Services. The second important characteristic of this course is that is has been designed to have no technical prerequisites. This is meant to be an aid to security management. If both management (process oriented) and system administrators (content oriented) have a common language to use in discussions - requirements can be established both more efficiently and effectively.

The next three courses are technically oriented and fill in the security architecture model taught in the first course. These are Q1341/AU41 AIX Security I: Host mechanisms; Q1342/AU42 AIX Security II: Intranet mechanisms and Q1343/AU43 AIX Security III: Internet mechanisms (Qxxxx are US Course codes alternatives for WWCC (Worldwide Course Codes beginning with AU/AM)). These courses each focus on a particular group of mechanisms to implement security services for a particular environment. The concepts security services, security mechanisms, and security objects are covered in detail in the overview course.

Why four courses? It seems like so many.

Well, I guess it could have been done as two five day courses, but there were several other issues. One was the expected audience for each course - which is different for each course. And the other was funding the course, i.e. security suite, development over a two-year period. One thing we were very aware of with the old single course was that you could not write a "please everyone" course. The student requirements were too diverse - in particular, security managers (or security officers) responsible for establishing security policy did not learn enough of what they wanted to learn, and too much of what they did not ever expect to use (or did not want to learn). Further, there was a need to update the technical training - right now! After some discussion we choose to develop a training schedule with four courses, any two in sequence would be five days. So the overview is two days, AIX Security I is three days, AIX Security II is two days, and AIX Security III is three days. Each country is able to schedule the course to best suit their audience requirements. For example, as curriculum manager, some months I schedule a week with Q1313/AU13 and AM40 (the WWCC for the security overview course; I dont know what course code the US has chosen) in one week, and AU41+ AU42 another week while other months I schedule the AM40+AU41 one week and AU42+AU43 another week.

So, in 2001 the AU41+AU42 courses were developed to replace the old AU41 course, and this year the AM40 and AU43 courses were developed. Right now the AU41+AU42 courses are being updated to AIX 5.2 and removing some overview material no longer needed now that the overview course is available.

Well, that seems pretty complete. Any future plans for more courses?

Actually, yes. We are discussing one additional course. If I were to give it a title it would be AIX Security IV: Intrusion Detection and Reporting. But I do not expect anything to be done for at least a year. We want to get more feedback from our students so that we can design the course with the right objectives and length. And, personally, I am undecided about the audience mix. In other words, should the focus be on technical aspects - buying/configuring intrusion detection systems running on AIX/UNIX, or on using the standard logging mechanisms on AIX to detect security breaches (building), or some mix. Please make sure your readers know that I am very interested in their needs to security training - and that I can be reached at mamfelt@ieee.org (or mamfelt@nl.ibm.com) for questions and comments. AND! sometime in 2003 or early 2004 I expect that we will have some kind of certification for AIX security. I am not involved in that process but I know it is being discussed.

Thank you for this interview!

  
AIX Security Resources

All AIX Courses at IBM US and IBM the Netherlands.

Strengthening AIX Security: A System-Hardening Approach (PDF)
This paper provides a baseline of AIX security for system administrators and offers guiding principles to help you begin securing your system.

Security Guide AIX V5.2 (PDF)
Part 1, "Standalone System Security," provides a baseline of AIX security for standalone systems.
Part 2, "Network and Internet Security," provides information about network and Internet security.
Part 3 contains the appendixes, which include security checklists, information about security tools, online security resources, and reference information about network services and communications ports.
Don't miss Appendix C. Summary of Common AIX System Services !

Additional AIX Security Tools on IBM eServer pSeries, IBM RS/6000, and SP/Cluster (HTML) or PDF.
From firewalls to operating system hardening, this redbook illustrates additional tools and techniques that you can use to enhance the security environment of your IBM pSeries, IBM RS/6000 workstation, SP, or Cluster. Subjects covered in this redbook include: Firewalls, Secure Remote Access, Network Mapping and Port Scanning, System Integrity, Securing AIX. 

eServer Security Planner
This planner from IBM will ask you some basic questions about your business environment and security goals. Then, based on how you answer, the planner will provide you with a list of security policy recommendations that you can use to begin protecting your operating system resources right away.

Security and privacy assessments & planning

Denial-of-Service attacks: Understanding network vulnerabilities (PDF)
Denial-of-Service (DoS) attacks is a phenomenon that has recently plagued a number of well-known online companies. This paper will explore DoS attack methods; best practices for implementing sound strategies for risk management; and how best to equip systems and people to recognize and respond to attacks should they occur.

Subscribe to IBM E-mail based Security Advisories and Technical Mailings

IBM Security Resource Center