Governance

At a time of great crisis, with many businesses closing down, people asked to stay at home, protect the NHS and save lives, taking an 80% government-backed business loan offered by the chancellor of the exchequer will naturally feel like an olive branch. Still, things are not always as they seem. After the treasury used taxpayers’ money to bail out the banks in 2008, bailing out businesses and bailing out the people sounds like justice. However, after investigating this as a business owner, I found that the way it works in practice is very different from how the chancellor presented it.

The initial interpretation is that if you borrow £100,000 to support your business, and despite best efforts, you were unable to pay back the loan, the bank could claim £80,000 from the government and potentially lose £20,000. Understandably, the bank would need to exercise some due diligence to mitigate this risk. People will believe this is how it works because this is what Rishi Sunak implied when he announced the scheme to help businesses. Now let’s move on to how it works in practice.

An application is made for £100,000 to keep your business up and running during the coronavirus lockdown. The first thing the banks want to know is how much property the company owns, how much you own personally as the business owner and any other assets available as collateral against the loan. This is expected given that the bank will take 20% of the risk. On borrowing £100,000, understandably, you will need to offer £20,000 assets to secure the loan against it, or credible cashflow projections which offset this risk to the bank. However, missing if you don’t ask, is the process followed in the event of your business defaulting on the loan.

Again, back to the £100,000 loan example. The bank asks the applicant about assets, and the applicant reports that his business has no property at all, and very little in the way of valuable equipment with any resale value. However, the applicant has £50,000 equity in his home. The bank accepts the loan application with your home as collateral. This is more than adequate to cover the £20,000 after the government pays 80%, but this is NOT how it works.

If your business defaults on loan payments, the bank will start by coming after you for the £50,000 equity in your home. Then, and only then, they will go to the government and claim 80% of the outstanding £50,000 of the loan; the £40,000 leaving a loss of £10,000 to the bank. Several journalists and politicians have brought up the subject of why should it be an 80% loan guarantee scheme, and why not 100% with the government taking all the risk. The fact is, changing it from 80% to 100% is useless for businesses and their owners. An increase from 80% to 100% will ONLY take away the remaining risk to the banks. Essentially, it is a loan guarantee for lenders, not a loan guarantee for borrowers.

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 3^rd 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 3^rd 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 3^rd party obligations

• Reporting requirements for non-compliance

• Human Resources requirements for new employees

• Requirements for all staff

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.

In previous blogs, ‘how much information is too much’ was discussed in detail along with how callers can compromise the supply chain with an inappropriate discussion which crosses lines. This article is a follow-up with more detailed examples for further clarity, and more within the context of how much information to include on professional profiles.

There will be a tendency to use details of employer’s clients to bolster your profile, but the message is clear, if you are willing to use your employer’s clients now to find a new job, you will most likely use your new employer’s clients in the future. This problem is significant in IT and is undoubtedly an issue in IT security. Here are some non-IT examples for illustration:  

• Taxi Driver – if someone was a taxi driver for five years and they were applying for a new job, an employer would expect them to state the dates they were a taxi driver, and either the name of the taxi firm or that they were a self-employed taxi driver. Nobody would expect a taxi driver list clients or journeys. Doing so would neither be practical nor appropriate. A taxi driver is unlikely to do this, but it does illustrate the point.

• Recruitment Agent – a similar example, an employer would not expect a recruiter to provide details of companies for which they recruit or people they have helped find work. Start date and end date is sufficient along with details of the job, such as specific domains of expertise. Willingness to disclose current employer’s clients illustrates the likelihood of revealing future employer’s clients.

• A burglar alarm installer would not list where they installed specific types of alarm systems

• Solicitors would not list their clients but would name the firm as their employer

Contracts of employment include confidentiality clauses, and separate non-disclosure agreements are often required.