This course is the first of 4 courses covering Domain 1 of the CSSLP, discussing general security concepts.
Learning Objectives
The objectives of this course are to provide you with an understanding of:
-
The CIA Triad
-
Authorization, Authentication, and Accounting
-
Design Principles
-
Security Models
-
Access Controls
-
Threat/Adversary Analysis
Intended Audience
This course is designed for those looking to take the Certified Secure Software Lifecycle Professional (CSSLP) certification
Prerequisites
Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.
Feedback
If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.
One of the forms of models that we have is called mandatory access control. Now, mandatory access control has some rather unique attributes. First off, it is a rule-based which means the access control in a mandatory access control model is implied rather than explicit. Subjects have labels that carry the two attributes plus others that I've mentioned before, the clearance and the need to know.
Objects carry their own label: Classification and category or compartment. These describe a label that the rules of the system will then use to enable or deny access of a subject to an object. The reference monitor in the mandatory access control system make certain that the rules are activated each and every time the access and the manipulation of an object by a subject is attempted.
By comparing the label of one to the label of the other, and then acting upon the logic of the rule as written. Then, we have one that is a different kind of model called discretionary access control. And this one is far more prevalent than a mandatory access control type. This one is often defined in a two-dimensional matrix, much like a spreadsheet. With object listed across one access and subjects listed down the other, the connection point or intersection of the column, which is the access control list with the capability table, which is on the row tied to the subject. Then, access is defined in that cell at that intersection.
Normally, this is considered to be explicit because whatever attribute is defined in the cell, that is the intersection between the access control list and the subject's capability table, which ranges from none to full control. It defines explicitly what the subject can do. This is the kind of system that would typically have as the global default, no access. And this is what we find in Windows, Macintosh and many Linux systems.
A very popular type is role-based access control, which you may see on the exam as RBAC or R-B-A-C. And just to clarify, RBAC will be used to refer to role-based and not rule-based, which also carries the same acronym RBAC. Now, role-based access control takes roles which sometimes are called groups and provides them a profile of access and objects to which they are able to grant access. The access granted is imparted by role membership.
So once the subject is defined in the system, they are connected to a role and they can be connected to multiple roles. It depends on the system design but a role dominates for a session. A log off and a log back on might provide the ability to take on a different role. But as you see, we have different kinds of architecture that enables role-based access control. This too is an implied type of access control system. And it is also called a nondiscretionary because the owner doesn't have the discretion to give refined access to a subject. That access is granted by their membership in a given role.
So we begin at the top with non-role based access control. Basically, each subject has either by mandatory or by discretionary means. They're granted access to some object or objects. We could have limited access through limited RBAC where you have some applications serving as your gateway into a particular role. And you may have access generally, which is outside of a role.
Then, as the migration continues from non-role based to full role-based, we might have that step called hybrid, where signing in puts you in a role through which you get access to various applications, systems, and through them, data. But you might also have a particular application that you use. Logging in directly into that application. And instead through that, you are now granted access.
Then, we have full RBAC access where you log in and everything that you have in the way of provisioned access and resources is given to you by your membership in a given role. Then, we have other variations on the theme of nondiscretionary access control. One is called originator-controlled, which assigns various parameters to control access and usage over the information's lifecycle. We have DRM or IRM. Either way, information rights management where it's used to control access normally to intellectual properties and the portability that is employed through the various platforms to access it.
Now this one, DRM, IRM, typically relies on cryptographic techniques to allow or deny access and to track various forms of its usage. And then we have usage control, which may have a time parameter that governs how it's possible to use this and when and for how long. Now, in looking at the role-based access control method in more detail, let's examine why it's called a nondiscretionary form of access control.
First off, we create a role. This is typically associated with a job position. Now, the caution is, that is not necessarily its title. But what in fact, the role is actually intending to do to fulfill its job duties. So the role is a group that is created in the access control directory system. And then, you connect members to it.
Now, membership in the role enables access. So whatever the rules are that are in place governing the role, its structure, and what it allows or denies, is now an implied form of access. Access is granted at whatever level in whatever way only by membership in that role. If there is no membership, there may be no access and there will never be any bypassing if the system is configured for full role access control.
So we have the subject assigned to the role. They have their own attributes, their own rights and their own functionality. Membership in the role adds or constraints that by adding a configuration and a functional structure that's imparted by the role itself. And that grants access to objects that that role is in the access control list for, or is granted by a rule. And this deals with the attributes, the various permissions, and specifically the functional use of the object being accessed in this way.
Lectures
Security Basics: CIA Triad and Functional Requirements (AAA Services) - Design Principles - Security Models - Security Models: State & Mode - Threat/Adversary Analysis
Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years. He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant. His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International. A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center. From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.
Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004. During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide. He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004. Mr. leo is an ISC2 Certified Instructor.