Defining Access Control Policies

Robert Broxup

Access Control comes in many different flavours depending on the business, the systems used, and the buildings protected. At the same time, access control has a generic theme. Consequently, the policies put in place will be similar across the board, even when specific implementations of access controls can be very different.

Sections of an Access Control Policy may seem self-explanatory; however, it is worth remembering that the policies will be read and adhered to by non-technical staff and staff not experienced in Information Security.

With this in mind, the following three points give an overview of the policy; which could be defined as three sections or presented as a single policy statement. It could be one section. The following are examples of what to think about when describing the policy.

  • Policy Statement – protecting access to systems is critical to maintaining the integrity of our technology and data while preventing unauthorised access
  • Background – Access Controls are necessary to restrict access to authorised personnel only
  • Policy Objective – the objective of this policy is to ensure that we have adequate controls in place to restrict access to systems and data.

Defining the scope of the policy is essential to show where and how it will be applied. Here are some examples of what to include:

  • Locations – this policy applies to our offices in London, Liverpool and Glasgow. Alternative policy documents may exist for different offices because of regional legislative differences.
  • Who – this policy applies to all employees, consultants and 3rd party vendors authorised to access our systems
  • What – this policy applies to the use of desktops, laptops, business systems and mobile devices

A specific section to document all technical terms and their definitions is essential for non-technical members of staff to understand. Examples could include Access Control, Users, Business System Accounts, Application Accounts, Privileged Accounts, Access Privileges or Permissions, Elevated Permissions, Services Accounts, Test Accounts and others.

Access Control Requirement sections could include:

  • All users must use a Unique ID to access systems
  • Define passwords following the Password Policy
  • Remote access must use two-factor authentication
  • Sessions lockout or screensaver activation after 15 minutes of inactivity

General principles would typically include:

  • Access provided based on Least Privilege and Need to Know
  • User account requests and approvals logged and documented
  • How the policy applies to vendor accounts, application and service accounts, system administration accounts, shared generic accounts and test accounts
  • Restricted access to service account passwords
  • Non-expiring passwords
  • User account access terminated when people leave the organisation
  • Accounts set to expire when contracts expire or after a period of inactivity
  • Adequate user identification when new passwords are requested

Principles specific to privileged accounts

  • For a privileged account, create it as a named user account and not a generic user account. E.g. “ADM.firstname.surname”
  • Privileged user accounts requested by line managers
  • Monitoring of privileged account usage

Other thoughts

  • Define what happens with vendor default user names and passwords
  • Define the policy on test accounts
  • Define any specific considerations for access control for 3rd party vendors and contractor user accounts

Different people and teams will have roles and responsibilities under this policy, and these need to be defined. Consider who will be responsible for the following policy roles:

  • Who has ultimate responsibility for the policy?
  • Who will review and approve the policy?
  • Who will develop and maintain the policy over time?
  • Who will be responsible for taking proactive steps to reinforce compliance?
  • Line Manager support for their direct reports in understanding the requirements
  • Commercial team responsibility for 3rd party obligations
  • Reporting requirements for non-compliance
  • Human Resources requirements for new employees
  • Requirements for all staff

CM to improve safety and security

Robert Broxup

Configuration Management (CM) needs to be a core process in software development and IT service management. In engineering disciplines, the product or service is only as good as the process used to create it or run it. CM focuses on:

  • Establishing and maintaining consistency
  • Provides the control and tracking throughout the lifecycle
  • Provides the visibility to demonstrate adherence to processes

Without this level of control and oversight, and lack of systematic change, problems are introduced during software, product or service development lifecycle such as:

  • Acceptance of incorrect requirements
  • Implementation of incorrect designs
  • Incorrect software tools and languages used for development
  • Testing of the wrong software or software versions
  • Performing the wrong tests of software and services
  • Release of incorrect versions of the software
  • Release of upgrades which undo previously fixed issues
  • Wrong staff recruited
  • Wrong training provided
  • Incorrect policies and product or service reviews undertaken
  • Incorrect documentation supplied

These issues can result in:

  • Wasted effort and money
  • Late delivery of software, solutions and upgrades
  • Failure to meet service level agreements
  • Security flaws introduced which leave data and customers exposed
  • Safety issues introduced or not prevented which lead to personal injury or death

Although this might initially sound over-dramatic, a look through history at some of the disasters reported in the media, show this is not the case.  CM originated in the US Department of Defence and is one of the controls to help mitigate against the introduction of safety and security issues. CM includes:

  • Configuration Items – identification of artefacts along with details of what information to store and how to control it
  • Change Management – control of how, when, what and where changes take place along with review and oversight.
  • Version Control – controlling access to artefacts and maintaining a history of changes to each artefact.
  • Release Management – focus on the delivery of software, products and services outside of the departments and teams responsible for the development
  • Baseline – identified set of files and directories used for one specific complete configuration of the system
  • Branch – identifies the point in time where two independent configurations diverge. From this point, systems evolve independently, such as catering for bespoke customer requirements. Where historical problems are identified and fixed, the developers need to apply the fix to multiple branches.

The paper data breach

Robert Broxup

In the digital age, businesses place much emphasis on protecting electronic data, but very little seems to have changed in the way of protecting data on paper. Here are a few examples:

  • Charity – I am often approached on the street by a representative of a charity wanting monthly donations by direct debit. While listening to information about the charity, large quantities of personal data are often visible. The number of times bank details, names and addresses from earlier in the day are visible to me while engaging with charity staff, is quite incredible. We are not talking about obscure charities, but mainstream national and international names.
  • Banking – I recently entered one of my banks and was asked questions in the doorway about insurance products. The sales approach was to find out what people needed, then arrange a follow-up call to discuss the needs in more detail. This information was visible on a clipboard which included full name, address and contact telephone number. Again, this was at a high-street bank branch.
  • Car Hire – I once arrived to collect a car, only to see all the customer contracts arranged on the counter for everyone to see. The top pages included full names and addresses, price information and contact telephone numbers. These included my details.
  • Street Stands – most people will have at some point been approached by people asking what broadband they use, or what utilities they have, a pretext for a conversation about how their services are better value for money. So much personal information is visible to other people as a result of this activity. With so many new brands emerging and advertising in this way, it is conceivable that someone could set up a stand for gathering information for identity fraud. Conversations are often very intrusive and far exceed what is reasonable. Street stands advertising credit cards have become very popular over the last couple of years.

People need to be more careful. Beyond what I observed while interacting with businesses, I have also noticed the following while working professionally over the years:

  • Printed documents left abandoned on a printer for everyone to see. This disclosure includes visitors, and staff that may not be authorised to know the content; not to mention cleaning companies which often have a high staff turnover. Printers are available that require people to log on to print their documents. Unprinted documents are deleted from the queue if not collected, which saves paper as well as improving data security.
  • Documents left in meeting rooms instead of being securely recycled
  • Visitor sign-in sheets which sometimes include more details than needed
  • Unlocked filing cabinets and desk draws
  • Documents left on desks overnight

It is clear that while a significant focus is on digital data protection, exposure of personal data on paper is high.

Unwise Software Installations

Robert Broxup

The issue of viruses, ransomware, spyware and other forms of malware intended to cause harm, has become much more of a hot topic in recent years. However, this has not translated into a comparable increase in vigilance and due diligence when it comes to choosing software vendors and websites. Although many attacks come from vulnerabilities in software, it is far easier for malicious software to find its way into your corporate environment by allowing staff to install software themselves.

Malware is becoming more sophisticated, and the quantity of malicious software is quickly increasing. Technical solutions are evolving to protect against malware, but the concern voiced here is the culture of software installation and usage.  When left unchecked, this can easily result in harm, loss of data, loss of reputation and business. Anti-malware solutions are essential but relying on such solutions while allowing any software to be installed by anyone for any reason is a dangerous approach. An extra level of defence is needed.

  • Restrict endpoint permissions so that only key members of staff have the authority to install the software. Needing to involve an authorised person or team to have new software installed requires a justification which slows down the process. Whereas, if just one person is involved, they can easily install software on a whim with very little in the way of thought about the implications.
  • Have a published white list of software for use within the business, and defined policies in place regarding how to install software, and how new software is selected. Promote awareness of software installation policies throughout the company. Again, this aims to slow down the installation process or, more precisely, increases the time between an end-user deciding they need a piece of software to the software being ready to use on their desktop.
  • Remove all unauthorised software. Implementation of software installation controls are often performed at a late stage in business development and seldom implemented during any start-up period. Therefore, it is highly likely that when there is a requirement to enforce control of software within a corporate environment, it is because the business has lost control of its software.
  • Identify all executables on desktops and which application they belong to and remove all other executables. This approach can be time-consuming, and a more viable strategy is to define a standard image for endpoints which includes the operating system and all the software applications used by most staff. Applying this standard build will remove all traces of the previous installation and any unauthorised legacy software. The outcome is two-fold, cleanup of all old software, and control of new software.
  • Don’t install software from unknown or untrusted sources. The fact is, it is effortless to search for software online, find anything that is needed, and install the software very quickly. Websites giving away malicious software often look very professional, and many sites mimic known websites to capitalise on the credibility of legitimate websites.

Slowing down the process and giving time for appropriate software to be chosen and installed is essential and cannot be over-emphasised.