Industry News
The Business of Security Management:
A Matrix-Based Approach to the Creation of Security Policies
Historically, many organizations have established system security ad hoc, responding reactively to the sudden appearance of individual threats and to the ongoing demands for regulatory compliance. Even now, security practices are often implemented without reference to or in the absence of a company-wide policy. Within a single enterprise, multiple security specialists and IT developers devise independent procedures to protect assets within their respective business units or areas of authority. In the past, when physical resources were the primary security targets, such a silo-based method may have sufficed. But today’s corporate environments are dependent upon intangible, information-based assets that cross business-unit boundaries and extend not only throughout the enterprise but also to external relationships with partners, vendors, and outsourcing firms. Threats to such assets expose companies to vulnerabilities and can lead to damaged reputations (the CNN Moment) and to loss of market share. What is required for protection is a comprehensive, business-focused approach to system security, one that allows management to mitigate, respond to, and recover from the crises that can proliferate in this rapidly changing risk landscape.
The Business of Security Management
HP defines its vision of the Converged Infrastructure as the means by which to manage an open, standardized IT organization via a “single pane of glass” view. Managing system security in such a converged environment necessitates an equally as seamless approach. It should be owned by business managers – not IT staff - and should be aligned with a corporation’s goals and strategies. A unified security approach is interdisciplinary. It reaches across people, processes, and technologies. Thus, the personnel who are assigned to merge security functions and to administer security policies typically do not have experience with the platforms on which security utilities are located or with the technical aspects of the facilities themselves. In the NonStop world, administrators tasked with the business of system-security management may have little direct exposure to an Integrity NonStop server and even less familiarity with Safeguard security software.
This presents a dilemma. How can a company’s security be implemented if those given the tasks are not experts, for instance, with complex command syntax? One solution is to split the role between business managers who define and administer the policies and developers who implement them. The complication here is that the human interface between businessman and developer can result in unintentional misunderstandings and errors, thereby creating additional security risks. Much more efficient is an alternative solution – that of building on top of a security utility a user-friendly layer, one that requires no knowledge of the underlying architecture and that allows security policies to be generated from easily understood business models. A tool that can serve as this business-oriented personality is an access matrix.
A Matrix-Based Approach
Wikipedia defines a matrix as a “rectangular array of quantities or expressions set out by rows and columns. It is treated as a single element and is manipulated according to rules.” In the corporate world, matrix management has been in use as a formal structure since the 1970s, when it gained broad acceptance after first being implemented by the United States’ National Aeronautical and Space Administration (NASA). Matrix management organizes people with similar skills, regardless of the business units to which staff are assigned, into new, flexible environments in order to complete cross-departmental or company-wide ventures. Matrix management has its detractors, but it is widely accepted as a method to ensure the timely completion of highly collaborative, complex projects.
Introducing the Access Matrix
As matrix management is a commonly understood business methodology, it becomes a logical extension to create a familiar matrix tool for use by security administrators. The access matrix, or access control matrix, is a formal security model that sets the rights of users to access or be denied access to system resources and sensitive data. Access matrices can serve as the user-friendly, intuitive layers that interface with underlying software such as HP Safeguard. They define in business terms the security relationships between users (role-based) and objects (applications, processes, data and other resources), and they provide effective controls for managing frequent changes in security permissions.
Building the Access Matrix
It is critical to the design of an access matrix that enough flexibility is built into the configuration to accommodate shifts in system security due to changes in the business environment. After all, the business of security management requires security protocols to be configured around the strategies that an organization pursues. Form follows direction, and updates may be frequent. Wizards as well as user-friendly graphical interfaces between matrices and underlying security utilities should be constructed to simplify management responsibilities. Remember, the goal here is to require little if any technical knowledge or training on the part of administrators.
The access matrix above is based on Access Control Lists (ACLs), one of the two access control models in use by current systems (the other is a capability-based model). The ACL-based model populates the matrix with rows of user profiles, or roles, as well as columns of object profiles - resources that require protection. Individual users and/or groups are linked to user profiles, and individual and/or group resources are linked to the appropriate object profiles. User profiles can be employee names or roles within a company - developers, operations, testers. Members of a user profile require identical access to an object. Members of an object profile require the same list of permissions, or ACLs, in order to be accessed.
Where columns and rows intersect determines the access privileges, or authorities, that are provided a user for any particular object. Some users possess many access permissions. Other users may have few. A developer may perform a big role on one system but have limited access to another system. This all evolves continuously to accommodate such organizational variables as functions, roles, processes and people.
The Access Matrix Frames a Security Policy Model
Designed properly, the access matrix offers a concise view of an enterprise’s security “intentions.” It is a policy model that establishes business rules by which to govern how people in the enterprise access system resources. The access matrix also allows oversight committees to make appropriate decisions if faced with the need for trade-offs between system access and protection.
Security Planning, Implementation, and Change Management
Once the access matrix has been selected as the policy model, it can be used for planning, implementation, and change management.
Defining a Security Plan
Defining a formal security plan and translating policy into practice can prove challenging, especially in an organization where past security initiatives were conducted in a disjointed, incompatible fashion. A security plan is a general statement of access restriction to system resources. It does not focus on implementation procedures. For example, application programmers cannot change production code is a general statement of a business need. Users DEV.* are denied WRITE access to disk files $D1.CODE.* is a specific configuration, one that is written at the underlying security-utility layer.
Migrating to a new policy model based on a business-focused access matrix typically demands more than a simple migration effort. First, administrators must thoroughly examine the company’s current security practices, i.e., the implementation procedures themselves. What is nice about access matrices is that they can be manipulated to provide visual representations of potential impacts to the organization before new policies are enforced or before existing policies are revoked.
In some cases, it may be necessary to “reverse engineer” an existing security policy in order to determine if it can be reconfigured to fit the new security plan’s language of business. Why was the existing security policy created? How is access presently controlled? Who is in charge of security permissions? Are there unnecessary redundancies in ACLs? How often are security practices reviewed for compliance? Does the policy help manage organizational risk or only that of a specific functional area? How often is the policy updated to address new security threats?
Another reason to investigate current security practices is to assess the impact of making changes. What are the differences between old and new policies, and why do they exist? If a new policy will involve stricter access rules, will it prevent some users from effectively performing their jobs?
Mapping the Plan into Practice
Security practice is the implementation of the security policy. It is the technical mechanism that enforces the policy, and it is defined in technical terms. This is where the high-level expression of security policy interacts with system configurations and is applied to the system infrastructure. Where the rubber meets the road, so to speak. It is therefore critical that whatever business-related policies are created by access matrices can be translated into terms understood by underlying software utilities.
In the HP NonStop environment, Safeguard is the primary security tool; and it is ACL-based. Thus, interfaces written between the user-friendly access matrix and Safeguard must employ Access Control List terminology (objects, users, authorities), must issue appropriate Safeguard commands, must link to essential Safeguard services (identification, authentication, authorization, accountability), and must comply with Safeguard’s ACL checking strategies.
All this, of course, is transparent to the security administrator, whose job description does not require Safeguard-fluency.
Managing Changes to Security Policies
Systems change – quite frequently, in fact. System changes may be due to external factors such as users leaving the company, the porting of new applications, or the consolidation of globally distributed services. Internal factors, e.g., moving disk files to a new disk volume, also create system change. Security policies change as well. They may remain fairly constant after an initial period of adjustment but still may require modifications as organizations choose to realign their business practices.
The beauty of a security access matrix is that once created, it easily can be updated to reflect altered or new policies. A well-built access matrix allows administrators to efficiently alter the links between users and changed user profiles and between objects and changed object profiles.
As an example, a developer whose user profile is displayed in the access matrix shown earlier decides to leave the organization. Upon his departure, all access privileges must be deleted from any object ACLs in which he appears. The security administrator 1) identifies the correct user profile; 2) finds the row (developer) in the access matrix where the user’s profile is located; 3) identifies each object profile for which the user has been granted access permissions; and 4) deletes the user’s entry from the access control list of each identified object. It is that simple.
Conclusion
Historically, many organizations have established system security via random, silo-based procedures, without reference to or in the complete absence of a company-wide policy. Today’s corporate environments are dependent upon intangible, information-based assets that cross business-unit boundaries and extend not only throughout the enterprise but also to external relationships with partners and vendors. Threats to such assets expose companies to vulnerabilities and damaged reputations. Thus, it is critical that security interests be aligned with a company’s business goals and strategies. One approach to this challenge is via the creation of a security asset matrix. It provides a single pane of glass, point-and-click solution to the business of security management; and administrators with no knowledge of systems or security utilities can transform easily understood business rules into real-world security policies. Click here for more information on ProtectXP
Vernette O’Neill Biography
Vernette O’Neill is President and CEO of Computer Security Products, Inc., an international specialist in HP NonStop server security and audit. A hands-on executive with years of experience in organizational administration and system-security design and planning, Vernette leads CSP’s global business efforts. Included within CSP’s popular product suite is ProtectXP®, a comprehensive, role-based solution that simplifies the management of enterprise-wide NonStop server security initiatives. Click here for more information on ProtectXP
To view the article in PDF Format Click Here