My co-author, Martin, works for Safestone Technologies, Inc., an IBM Business Partner that specializes in iSeries compliance and security management. As Safestone's lead technical support for the United States, Martin has a very strong background in OS/400 and i5/OS security implementation.
As the former lead security architect for OS/400 and i5/OS and the current security architect for IBM's Virtualization Engine product, I've learned a lot about computer security and security in general. I've found that most computer professionals--and even many individuals who consider themselves security savvy--are a lot like I was when I first started working in security. They don't really understand the nature of security. But for most of us in today's world, this is no longer acceptable. Because of my job responsibilities, I had to learn it a little earlier than most.
So every other month, I'll be writing about security concepts and issues. I'll be taking the opportunity to share my thoughts and opinions on security (some of which might be considered controversial) related both to OS/400 and i5/OS specifically and to the industry in general. My goal is to provide a different perspective on security, which, in turn, may help you make better security decisions for you and your employer. In addition, I hope to provide you with concrete evidence as to why OS/400 and i5/OS provide the most cost-effective security management available in the commercial market today.
On alternate months, Martin will provide "how-to" articles that explain how to exploit some of the myriad of security functions, features, and tools available in i5/OS. And via Martin, you may hear from some Business Partners also. Occasionally, Martin will select topics that help show how to implement a feature or concept that I discussed in the previous month's column.
To set the stage for future columns, I'm going to make what might, at first, appear to be a very controversial statement. And then I'll explain why it's not really so controversial. All of this is to serve the purpose of explaining my definition of "security."
Here's the statement:
"Any version of Microsoft Windows operating system (I don't care which one) can be used just as securely as any other operating system, including i5/OS!"
You might be asking yourself right now, "What on earth can he possibly be thinking?"
To understand why this statement isn't controversial, let's first look at the definition of security. According to Merriam-Webster Medical Dictionary, "security" is "the state of being free from danger or injury" or "measures taken as a precaution against theft or espionage or sabotage, etc." (www.dictionary.com, last definition at the bottom of the page). A "state of being" implies a condition or value, not a concrete, finite, or measurable entity that can be applied to inanimate objects. The phrase "measures taken" implies processes and procedures.
It follows from these definitions that "security" is not an attribute of inanimate objects such as computer hardware, software, or applications. You can have security. An inanimate object can be secured, i.e., made free from danger or injury. I think of security as something you do in order to be free of danger or harm.
Yet we, as individuals and the computer security industry in general, talk about computers and applications as being "secure" or having or providing "security." We often hear about the need to "buy" security products. Clearly, there is no product that provides a "state of being" or "measures taken."
Don't get me wrong. Security features, tools, functions, and products are necessary for you to achieve the level of security you or your company require. It's just that these things are not sufficient! They alone cannot and do not provide you with security. It's what you do with them and how you do it that provides your state of well-being.
Take, for example, a high-security prison. What makes it a high-security prison? Is it the physical walls, bars, and various technical devices alone that make it secure? What if there were no guards? What if there were no procedures for how prisoners, guests, and employees were allowed to enter, leave, and move about the prison? The absence of such procedures would render all the physical objects and technology in the world moot. On the other hand, good processes and procedures can overcome a lack of physical resources or technology. The same is true for computer systems and applications.
Let's look again at the statement I made. You may have noticed that I used phrasing that you don't normally hear when talking about security. I said "can be used as securely as...". I didn't say "is just as secure as...". The primary reason I didn't was because such a statement--no matter which operating system it is applied to--has no meaning. By definition, an operating system cannot have a state of being or take measures on its own volition.
Even though I technically believe the "controversial" statement I made above, I hope that you now see that such a statement is a moot point. It doesn't matter how securely a thing can be used; the important thing is what processes and procedures you have to employ to use them securely.
So what differentiates one operating system from another with respect to security? It's simple. It's the cost to achieve the level of security you desire. It's not about how secure an operating system is; we've already shown that security is not an attribute of an operating system. It's all about how much it costs you to secure an operating system to meet your definition of security.
A corollary to the cost of securing being a differentiator is that the more complex or expensive it is to secure anything, the more likely it is that something you should do will be left undone or done incorrectly, thus leaving you with less security. Stated differently, the cost--in both time and money--of securing a system is inversely related to how well that system will be secured.
So, while I believe it is possible to secure any operating system to virtually any level required, I also strongly believe that this is completely irrelevant. How much security you ultimately have depends on how much it costs you to secure your system, not the theoretical fact that a system can be secured.
Now that you have an idea of where I'm coming from when I talk about security, I'll make one more, hopefully less controversial, statement:
"I believe that securing i5/OS is much easier and less expensive than securing other commercially available operating systems."
Proving or disproving this statement, while possible, would require a sophisticated sort of “bakeoff” with participation from the different platforms, which is unlikely to happen. Instead, I'll share some of my rationale and examples for believing this here and provide more in future columns.
All of the rationale stems from one of the primary objectives of the iSeries platform and the OS/400 operating system: Reduce the complexity and cost of managing computer systems. The original architects recognized that the process of securing a system and the data on it was one of the things that significantly affects the overall complexity and cost of managing a system. Therefore, architectural design and implementation decisions related to security were explicitly made from the start--from the hardware up to the highest levels of the system. All kinds of bells and whistles were integrated into the overall architecture to achieve this objective. Then, over the years, as new technologies and new security mechanisms became available, they were integrated into the system architecture rather than added on top of it. Reduce the cost and complexity of securing a system and you increase the probability that a system will be properly secured.
Consider just a couple of the more obvious examples of bells and whistles that were either built in from the start or tightly integrated later. First, the architecture of i5/OS is such that it is not susceptible to "root" takeover via buffer overflow attacks. Because it uses separate buffers for data and instructions, the worst that can happen is a software server might crash. Many IT organizations spend a large amount of money on countermeasures for buffer overflow attacks, but i5/OS customers don't spend any. Second, the object-based nature of the system prevents the execution of a file containing executable code but masquerading as data, a common tactic of worms and viruses. How much do IT organizations spend on preventing viruses from executing on other systems?
These things don't make i5/OS more secure. They make it much more likely that you will properly secure your system. And after all, that's what security is really all about. Isn't it?
Patrick Botz is currently responsible for security within IBM’s Virtualization Engine. Prior to that, he was the lead security architect for OS/400 and i5/OS. Pat was also the lead architect for IBM’s Server Group’s Single Sign-On. He started his career maintaining basic compilers, moved on to Electronic Computer Aided Design development and support in distributed UNIX environments. Along with Carol Woodbury, Pat recently co-authored the book Experts' Guide to OS/400 and i5/OS Security and is working on another devoted to eliminating passwords on server systems.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online