Search This Blog

Monday, December 3, 2007

Implement Role-Based Access Control for Stronger Security

Good computer security is driven by role-based, least-privilege access
control. Each user should be given only the access that is necessary
to perform their job -- no, make that the specific task they are
performing at a specific point in time. Unfortunately, even though RBAC
(role-based access control) was formally introduced in 1992, it is still
in its infancy on most platforms. There are many role-based management
tools that work in Windows, Linux, and other OSes, but the most popular
products work with only a few large products (that is, SAP, PeopleSoft,
and so on) or just haven't been widely adopted. There are also many
developing RBAC initiatives, such as the OASIS XML-based RBAC effort
for Web-based content ["Core and Hierarchical Role Based Access Control
(RBAC) Profile of XACML v2.0]. Why investigate RBAC solutions? They're
a good way to implement stronger security in your environment, and often
it is required. Many industry-wide regulations, such as the Payment Card
Industry Data Security Standard (PCI DSS), require role-based security
(PDF). If you're required to support PCI DSS in your environment, review
section 7. Hospital and health-care-related entities are already aware
that Health Insurance Portability and Accountability Act of 1996 (HIPAA)
mandates use RBAC to protect patient information. The vision of RBAC
security is this: No one knows better what security permissions or rights
should be needed by a particular end-user when performing a particular
task than the developer of the application. Unfortunately, this particular
assumption is largely untrue. In general, most developers don't have a
clue about the security needed to run their application. They just know
the application runs perfectly fine when given Administrator or root
privileges. This attitude is changing, with Windows Vista's User Account
Control (UAC), Linux's sudo, and better development tools that allow
needed security to be measured and defined. More Information

No comments: