Thinking Security: Can I Get In There, Please?
Author(s): Michael Kain, Posted on March 30th, 2016
This is the 15th blog in a series about security and how security is about how you think.
In this blog post, we’ll concentrate on the second goal of security: Access Control. Now we all know some of the traditional uses of access control. For example, we all use some form of badge in order for us to access certain rooms in work or in a generic building. We may have even used other items to prove our identity (fingerprints, perhaps retina scans or other biometrics) to identify ourselves and therefore control which areas we can access.
But access control is more than that – it’s the ways presented by the environment that allow us to control what identities can access what objects. In computers, it’s the ways that the systems give us to control access to programs or users. There are some “rooms” – objects like printers, disk files, and network ports that can be controlled, but beyond basic access, it’s also the operations that an authorized used can do (see the previous blog post about my thermostat); someone might be authorized to perform certain actions on the target object but prevented from performing others. This aspect of access control is usually called “permissions” or “privileges”. Sometimes they are grouped into “roles” that make the management of the system easier.
Many computer professionals are familiar with the “owner/group/world” model of POSIX for disk file (and directories in the Linux world), which is a de facto standard in the computer industry for file access control. Another common way to define privileges is with an “access control list (ACL)” in which each identity (computer user) has an entry in which its access to a particular resource is described. ACLs usually also distinguish types of object access (think read-only vs writeable).
We can compare different environments in several ways:
- Are all the objects (“rooms” if we’re talking about a building) protected by access controls?
- Are the control mechanisms easy to implement and are they consistently applied across all objects presented?
- Are all accesses (both successful and unsuccessful) logged appropriately? Forensic analysis of access control is one of the key problems here – think about the role of the security guard reviewing the list of people who have “badged in” during a day. How does he find who’s trying to break in?
- How easy is it to deploy the appropriate access control across the entire system and validate how access control is done so that you can check to make sure that it’s done correctly? For example, how do you know that the right people can do the operations that they should and no more?
Now, let’s use the analogy of a business to illustrate these concepts. (Even I’m not paranoid enough to use this on my home). I’d like to have an access control system which controls all of the doors and windows, and of course, all of my appliances, including my Internet-attached toaster in the break room. So, let’s not get too crazy, but I’d want a badge system for every employee so that they can badge into every room of the building (yes, I’m security paranoid). I might even want to have different types of access. For instance, if I have shared resources in a room (think rare reference documents in a library), I might want certain people (staff librarians) to enter the room and remove materials but limit others to only using the materials within the room. I’d want enough badge access points to deploy throughout my building and would want to be able to change them from a central spot (without having to go to each access point to change the access – that would be really a pain!). And I’d want that central management system to also provide an auditable log of access (both successful and unsuccessful).
So, the success of any access control is how easy it is to actually deploy. ClearPath MCP has the concept of a GUARDFILE, which allows the owner to describe what user and programs can have access. This is extendable to databases and which operations can be performed by the caller – so it’s better than access control lists in other operating systems. The same GUARDFILE can be applied to every object (file, database, etc.) on the system so that it is consistent. Similarly, on ClearPath OS 2200, Access Control Records (ACRs) are analogous to access control lists and GUARDFILEs. They can be attached to objects (files, user records, etc.) to control access, and they can be referenced by database access controls. In both systems, all access control is logged by the system so that it can be analyzed later to ensure that all accesses were validated.
This is a very concrete way to think about access control – who can do what, or who can get access to what. It’s a big job to think of every point of access within a building or computer system, so it’s really about how you think and how easy that it is to do this correctly. This process works the same way from a house or building to a complex, mission-critical computer system – so it’s how you think about security to make sure that it’s done right.