ASPECTS OF A SECURE SYSTEM

Introduction
This paper will describe several models or methods for helping to create a secure system. There are multiple aspects that must come together to create a secure computing system, these aspects include: 1) user and file monitoring and surveillance; 2) intrusion detection; and 3) user access-control mechanisms. This paper will discuss the models presented in the papers: Computer Security Threat Monitoring and Surveillance (Anderson 1980), An IntrusionDetection Model (Denning 1987), RBAC (Sandhu 1996), and NIST RBAC (Sandhu, Ferraiolo & Kuhn 2000). It will explain the ideas behind the models and describe how they work and can be used together to make a system secure.

Abstract
This paper describes and explains several components of a secure computer system. It will discuss threat monitoring and surveillance, Intrusion-Detection, and Role-Based Access-Control. When combining some or all of these methods or models it can create a secure computing system safe from most attacks or intrusions; Not only from outside sources but from inside as well. Keywords: Security, Access-Control, Intrusion-Detection, Auditing, Models, Roles, Threats, Monitoring

Threat Monitoring and Surveillance

Threats
Threats are broken down into categories based on how much access, if any, the user is authorized to have on the given system or a given resource on that system. There are two general categories of threats; external penetration and internal penetration (Anderson 1980). External Penetration An external penetration attack can be either an outsider to the company or a person from within the company that is not authorized to use the computer system. If the attacker is an outsider of the company they are more limited in their methods of attack. For example, if all of the system is contained within the physical building of the company through the use of their own servers and terminals then the person from within the company who may have access to the building housing the system has a much easier time than the outsider who has no way to get through the system to launch an external penetration attack. If, on the other hand the company is using a wired communication line to the outside the outsider has a much easier time getting into their systems by tapping the line (1980). In the event that an attacker is trying to break in from the outside through an unprotected line of communication, they would likely not be detected in most systems. Most systems are large enough that it is not feasible to record logs of attempted log on attempts as it would consume too many system resources and would not be worth it. The attacker from within the company in this scenario is much more likely to be caught or known about. Once the external penetration attacker penetrates the installation access controls of a system the attack becomes an internal penetration attack(1980). Internal Penetration Internal penetration attacks occur more frequently than external penetration attacks and as said before, can themselves come from an initial external penetration attack. Internal penetration attacks are sometimes difficult to identify as the attacker has already over come one of the largest obstacles to launch their attack; they are authorized to use a machine in the system. There are three classes of internal penetration attacks, they are: 1) the masquerader 2) the legitimate user, and 3) the clandestine user (1980). Each one of these classes has varying degrees of difficulty in detecting and operate in different ways on the system.

Florida State University iSchool

The masquerader is any user on the system who is exploiting another users identification and password obtained through any number of ways. Can be anybody on the system including an external penetrator who has successfully bypassed the access controls. There is no immediate discernible way to tell the masquerader from the legitimate user because as far as the system is concerned, if they have the user name and password it must be the legitimate user. It is however possible to detect a masquerader by examining audit trail records looking at things such as; 1) time of access 2) frequency of access 3) amount of data reference, and 4) abnormal patterns of data or program reference (1980). The way a masquerader is detected is by doing something that the legitimate user would not normally do such as accessing the system at weird hours many times. A legitimate user is authorized to use the system so the audit trail records would likely not show any abnormalities as it would with a masquerader. If a legitimate user tries to do something they are not given access to do however, such as access a file they are not supposed to, it should show In the audit records. If the legitimate user only slightly misuses their authority it is likely to not result in detection as a good method for finding very minor abnormalities is likely not feasible to implement. The clandestine user is the most difficult type of internal penetration to detect. A clandestine user is one that has seized control of supervisory controls on the system. This allows the user to operate at a lower level than which the audit system is running. There is no way to detect the clandestine user once they are passed the audit system, as far as the system is concerned they are not there and no data is being gathered about what they are doing.

Surveillance

Intrusion-Detection
Denning's model for intrusion-detection describes a real-time matching of audit records with users profiles. Using this system, security violations can be detected by monitoring audit records for abnormalities. This model works by creating a profile for a user and given their behaviors creating a confidence interval for any given task they may perform, each time the user performs this task the confidence interval increases. Likewise, the confidence interval decreases when they do not access parts of the system or use certain resources. Every action by the user is then checked in real time against the confidence interval for whatever they may be doing using standard deviation. The model provides framework for a general purpose system that can be used on almost any existing system independent of operating system. The first step of the intrusion-detection system or IDS is to establish profile templates for the user. The system only looks for deviations in usage on the system for any given user. The IDS only detects possible threats and alerts the security officer or other official, it does nothing to prevent the attack.

Profiles
A user's profile is created the first time a user logs into the system. Every time a user does something on the system it is added to their profile. As the users profile builds up over time it is easy to distinguish trends of usage for that user. For example, if a user logs on to the system every single day at 9:00AM when they get to work and logs off at 5:00PM as they leave this information will be entered into their profile. After weeks of doing this routine exactly the user logs onto the system at 8:00AM or stays late, logged on until 6:00PM this behavior clearly goes against the users established profile and would send an exception to the security officer letting them know that the user is doing something out of the ordinary. A user's profile contains all kinds of information about their behavior on the system. Not only does it show what times they log in and out but also what files they usually access and how often. Their profile can contain information on how much they input into the system on average and how much they get the system to output to them. This allows a very in depth and detailed analysis of what that particular user does on the system and what you can expect them to do next time they log on. When a new user joins the system there are several potential problems. The initial lack of profile information may generate a large number of anomaly records for the user. The system my also not be able to detect an intrusion by the new user is they do or access something they should not before their profile is built. There are a few ways to try to combat these problems however. To help against the large number of anomaly records being generated you can start the user with a large confidence interval then gradually shrink it as they use the system longer (Denning 1987). This solution does not work for every problem however, it does nothing to prevent the new user from abusing the

Florida State University iSchool

system it only decreases the number of false alerts they may send out. Likewise, another possible solution is to start the user with a generic profile based on one or many users of the system (1987). This solution helps prevent the new user from abusing the system but does not prevent all of the anomaly records they may generate if they use the system differently than other users. One last concern with adding a new user to the system is that they may purposefully generate a profile with the intent of doing harm to the system, they can do this by slowly over time accessing the same parts of the system or slowly expanding the depth of their access into the system as to not generate any anomaly records.

Audit Records
An audit record is represented by 6-tuples and shows actions performed by subjects on objects. An audit record is in the form of: <Subject,Action,Object,Exception-Condition,Resource-Usage,Time-stamp>(1987). Audit records are what is checked against a users profile to determine if they are trying to abuse the system in any way. Every time a user perform an action on the system an audit record is made, it records what they were doing, what they were doing it to, and what time they did it among other things. There are two basic strategies of auditing and both are used for different tasks in the system. The first, is to audit something as it is attempted. This is used for things such as login, high risk commands, and access to sensitive data (1987). Some audits however are not sent as soon as the task is attempted but waiting until after a task in completed to send the audit report. This allows for more information to be gathered such as the amount of resources spent on an operation, this is generally used with creating or modifying files.

Role-Based Access-Control
Model
In the Role-Based Access-Control(RBAC) model, permissions are assigned to roles instead of individual users, users are then assigned to the roles which have the permissions they require. Roles are generally created for various jobs or functions within an organization. This model is used today because it is easy to assign users to any given role as well as add or remove permissions from a role. You also never have to assign each individual their permissions, this saves time and greatly limits on mistakes. Another way RBAC is much easier to manage is that if you want to see which users have which permissions you can just see who is assigned to what role, you don't have to look through each individual user. In the RBAC model there is a many-to-many relationship between user assignment (UA) and permission assignment (PA), that is that many permissions can be assigned to many roles and many users and be assigned to many roles. When a user is in more than one role they can activate any subset of these roles during a session. This allows the user to keep more powerful roles deactivated and only activate them as needed, this limits the possibilities of mistakes or misuse of the system.

Constraints
The inclusion of constraints in the RBAC model is sometimes argued to be the reason why it is so widely used (Sandhu 1996). These constraints allow a lot of flexibility and customization to any particular needs. There are three main types of constraints; 1) Mutually exclusive roles 2) Cardinality constraints, and 3) Prerequisite roles. Constraints are not required to be used at all as will be discussed later with the NIST models of RBAC. Mutually Exclusive Roles The inclusion of mutually exclusive role constraints enforces the separation of duties. One a certain role is declared to be mutually exclusive a given user of that role can not be added to another role in the same mutually exclusive set this enforces mutually exclusive roles on UA. This allows users to not be assigned to two roles that may have a conflict of interest. For example, if a user was assigned to be both a salesperson and an accountant who calculates how much a salesperson gets paid based on their wages and commission, a problem is likely to arise. This person may be tempted to give themselves a little bit extra money or fake a sale and add more commission and they could easily do this if they were allowed to be in both of these roles. Another type of mutually exclusive role constraint is

Florida State University iSchool

on PA, where a given permission is only assigned to one role. Supposed in the above example the salesperson role is given the permission to write paychecks, we are in the same situation as before but this time because the permissions instead of the users. Cardinality Constraints Cardinality constraints limit the numbers associated with a role or person. A cardinality constraint on PA would be limiting the number of roles that can be assigned a given permission such as the ability to hold a meeting, only high ranking people or managers of a certain branch or part of the office would need this. A cardinality constraint on UA might be to limit the number of roles a user can be in or limit the amount of members a specific role can have in it. These types of constraints help limit power and organize better. Prerequisite roles This type of constraint only allows a user to be added to a role B if they are already part of another role, A(1996). This can be used to enforce a rule on being the chairperson or official of some group, you cant be given the role of chairperson if you are not a member of the committee for which it is pertaining to.

NIST RBAC
Model
The National Institute of Standards and Technology (NIST) proposed a standard references model for RBAC. There had been a lack of standards so roles were implemented in various different ways in different RBAC systems. This hurt the RBAC system itself by making it mean different things to different people depending on the implementation they were familiar with. NIST proposed to standardize RBAC by splitting it into four categories, each with more rigid rules and standards than the last. Each different RBAC model is useable depending on what your needs are. Each step up in the RBAC models requires all of the components of the model previous to it, i.e. if you were to have a constrained RBAC model you must have all of the requirements of a flat and hierarchical RBAC model as well. Flat RBAC the flat RBAC model is the already widely deployed and familiar model. The only requirements of the flat RBAC is that the permission role assignment can be many-to-many, the roles assigned to a specific user can be determined as well as users assigned to a specific role, and users can exercise permissions of multiple roles at the same time(Sandhu 2000). These requirements allow the system to be easier to manage, you are easily able to see which user is in which role. It also provides the fundamental elements of RBAC such as being able to be in multiple roles and have multiple permissions. Hierarchical RBAC Hierarchical RBAC adds the need to support role hierarchies. There are two types of hierarchical RBAC systems: General Hierarchical RBAC and Restricted Hierarchical RBAC. Restricted Hierarchical RBAC allows the system to impose restrictions on the role hierarchy(2000). Either of these two Hierarchies can be either an inheritance hierarchy, where activation of a role activates all roles it inherits from, or activation hierarchy where activating a role does not activate other roles(2000). The adding of hierarchies increased organization and management. Constrained RBAC constrained RBAC adds the requirement of implementing a mutually exclusive roles constraint to enforce separation of duties. As discussed earlier, Separation of duties provided by these constraints adds security and reduces the chance of fraudulent behavior. Symmetric RBAC Symmetric RBAC adds the requirement of a permission role review such as the one required of users in the flat RBAC model. This allows you to see the permissions assigned to a specific role as the user role review did for users.

Conclusion
No one method of security is enough to protect a system. Every security model or methods have their purposes,

Florida State University iSchool

strengths, and weaknesses. If you were to use an IDS on your companies computer system and nothing else it would not help you at all. You would know when somebody was misusing or breaking into your system but you would not have the means to prevent it. RBAC lets you control and manage your users easily and effectively helping to prevent the misuse of the system by limiting their power, but if a user was masquerading as a user with more power you may not know unless you were also using an IDS as they are likely to do something outside of the users given profile. Any given system can never be 100% secure, but to have a sufficiently secure system you must implement more than one layer of security. These systems are meant to act supplementary to other systems already in place, no one system is enough for total coverage for your system.

References
Anderson, J. Computer Security Threat Monitoring and Surveillance. Forth Washington, PA: James P. Anderson Co., April 1980 Sandhu R., Coyne, E.J., Feinstein, H.L., and Youman, C.E., Role-Based Access Control Models. IEEE Computer, 29(2), Feb 1996, PP. 38-47. Sandhu, R., Ferraiolo, D., and Kuhn, R. The NIST Model for Role-Based Access Control: Towards A Unified Standard. Laboratory for Information Security Technology (LIST), George Mason Univ., 2000. Denning, D.E. (1987). An Intrusion-Detection Model, IEEE Transactions on Software Engineering, 13(2):222232, February 1987.

Florida State University iSchool