AIX > Administrator > Security

Howdy, Partner! The Role of Application Developers in IT Security


Responsibility for security—and access control in particular—has long been assumed to belong solely to system or security administrators. I’m not really sure how or why this became so widely accepted as truth. Perhaps it’s an outgrowth of the prevailing culture in IT shop, where IT’s overriding priority has been to ensure that systems and data are always available. In this environment, administrators focus on ensuring that no users encounter authority failures rather than on making sure data is appropriately protected. When authority failures do occur, everyone inside and outside of IT assumes it’s the administrator’s responsibility to “fix” them. Nine times out of 10, whatever fix is applied leads to data being even less tightly protected.

Regardless of the source, the assumption that administrators are solely responsible for access control (i.e., fixing authority failures) is guaranteed to result in very poorly protected systems. What does the administrator really know about the details of the implementation of an application and which data is used, or whether that data is merely read or changed? He’s not familiar with the architecture of the application. She doesn’t know how much or how little authority is needed to specific objects by particular programs in an application. Even if he or she is well versed in these things, data is often used by multiple applications or directly through native internal or external interfaces. How can he or she know if limiting access to an object for a particular person for a specific program or application won’t break another application; or if the user also needs to access the object through native or external interfaces?

The answer is that administrators can’t possibly know enough about applications, the data those applications manipulate or how that data is manipulated to be able to appropriately protect them.

So what happens? Typically, data is “protected” by ensuring that anyone who has a valid userID and password on the system is given read and write authority. And this is typically done by making the default (a.k.a., world, other or PUBLIC) authority of read and write. Sometimes it’s done by giving everyone the equivalent of root privileges. I’ve seen more than one system where everyone is ensured all authority to nearly all objects through multiple mechanisms. That is, the default authority to all data is read, write and execute and all users have root privilege, and all programs are setuid with root as the owner.

It’s no wonder that so many data breaches occur. We pretty much ensure they’ll occur when we assume that administrators have sole responsibility for protecting systems!

Who else is responsible? Developers, that’s who.

One might argue that developers don’t necessarily know how data is used by people when those people aren’t running the developer’s application. And that’s perfectly true. But they don’t have to know this to carry out their security responsibilities.

Data Security Is a Partnership

Properly protecting access to data requires a partnership between developers and administrators.

  • The application architect/developer role is to create applications that provide their own authority to data irrespective of the user running the application.
  • Administrators, on the other hand, should be responsible for managing which users are allowed to run which applications or programs.

These two roles working together lead to much more secure data and access control schemes that are easy to manage.

If a user is authorized to run an application or program, then the program itself should ensure that the process or job in which the program is running has the necessary authority to the data being manipulated by that program. The job’s authority to objects must not depend on the assumption that the user has the required authority to the data.

In fact, users should very rarely have any authority to data. The vast majority should only need to be authorized to use programs.

The Importance of Job Authority

The concept of job or process authority is probably foreign to most developers, but it’s not new. It’s as old as the first access control functionality in computer systems. In order to wrap your head around it though, you must put aside, for the moment, the normal verbiage used when discussing access control.

The normal verbiage is that users cannot access data unless they’re authorized to do so. UserIDs can be authorized to data. UserIDs can be members of groups. If a group is authorized to data and a user is a member of that group, then the user is authorized to the data. If a user tries to access an object and they’re not authorized, an authority failure occurs. Finally, when a user runs a program, the program runs with the authority of the user and any group or groups of which the user is a member. This is all true.

But the verbiage we normally use is only part of the story. Yes, at the moment a new job or process is started, the list of users and groups associated with that job consists of the userID that started the job and the group or groups of which that user is a member. However, we don’t very often talk about how developers can add to or completely change the list of users and groups associated with the job. And this is how developers can ensure that a program attains the authority to data necessary to avoid authority failures.

In a recent Botz Security Bytes blog post, Access Control: What Most Developers Don’t Know Can Compromise Security, I talked about the idea that it’s the authority of the job that’s checked at the time a program attempts to access data, not the person or entity that started the job. Developers and, to a lesser extent, administrators have several tools they can use to ensure a job has the necessary authority.

Patrick Botz is the principal consultant and founder of Botz & Associates Inc., architect of the SSO stat! service and former head of the IBM Lab Services Security Consulting practice. He can be reached via www.botzandassociates.com.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.


comments powered by Disqus

Advertisement

Advertisement

2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Hardening the Cloud

Security considerations to protect your organization

Verify System Integrity

AIX 6.1 and Trusted Execution help ensure secure systems

A Bankable Solution

AIX Cryptographic Services improves security while simplifying administration

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
AIX News Sign Up Today! Past News Letters