Business Needs for Security Tool
Overview
The business needs for security tool is an instrument meant to be used by departmental business and legal analysts with help from the security advisor. It should be used to help the security advisor develop a legal and regulatory view of the department for the purposes of designing secure information systems. However, this tool is not necessary in cases where a department already has a detailed repository of legal and regulatory information that can be converted into security needs.
Note: The term "security advisor" is used to describe an individual or team possessing the broad knowledge and experience required to make and elaborate risk management recommendations to a departmental authorizer.
As shown on the left, this tool supports departmental risk management. In conjunction with the security categorization tool, it is used to help define the business context of security control profiles.
A business need for security is any protection or compliance requirement that ensures the confidentiality, integrity or availability of a business activity or information assets supporting a business activity.
Business needs for security are derived from:
- Laws (e.g. Employment Insurance Act, Financial Administration Act, etc.);
- Policies (e.g. Policy on Financial Management, Information and Reporting); and
- Any other regulatory instruments such as directives and standards governing GC business activities.
Business needs for security can also be derived from departmental missions, objectives, priorities, the need to preserve the organization's image and reputation, and various obligations that may have been contracted.
As shown on the right, BNSs are security requirements expressed at the conceptual (business) layer. BNSs generally make no reference to information systems, information system technology, solutions, or mechanisms.
However, they can create additional security requirements, as shown in the image on the left.
The analysis of BNSs consists of two steps: (1) Take inventory of the laws, regulations, acts, policies, directives, contractual agreements, MOUs, LOAs, etc. that govern the department, and; (2) Locate business needs for security within each instrument.
For more information, please read the Business Needs for Security Tool document and Excel spreadsheet.
Step 1: Inventory the Regulatory Instruments that Govern the Business
In this step, the objective is to find and record all key documents and regulatory instruments that apply to departmental business activities.
Many departments have a public repository of the regulatory instruments to which they are bound.
Security advisors should engage the business community within the department or agency to perform this activity. In particular, the legal function within a department or agency should be involved as a source of review with respect to legal and regulatory instruments.
The BNS inventory should be performed as one or more focus groups with the business community. It is vital that business and legal analysts are invested in this process so that linkages between BNSs and business activities are validated. Obtaining useful participation will take varying levels of preparation. The security advisor's task in this phase is to organize focus groups where possible, describe the task to be completed, emphasize the importance of their contribution, and to record and playback the results for validation.
For more information, please read the Business Needs for Security Tool document and Excel spreadsheet.
Step 2: Identify Business Needs for Security
In this step, the objective is to examine the applicable instruments to identify and extract statements that impose a BNS.
For common or widely applicable instruments, this identification may already have been performed.
Once a list has been obtained of sources that apply to the business context or domain (laws, regulations, acts, policies, directives, contractual agreements, MOUs, LOAs, etc.), the next step is to analyze them for BNSs.
Analysis consists of two steps:
- Check the most current version of the BNS tool to see if any of your source documents have already been analyzed.
- If not, create a new entry, perform the analysis, and share the results. Performing an analysis involves:
- Creating a new analysis tab from the template.
- Identifying BNSs in the regulatory instrument.
For more information, please read the Business Needs for Security Tool document and Excel spreadsheet.
Tips and Advice for BNS Analysis
Policies, acts, and regulations describe rights and obligations in complex and sometimes ambiguous language. There are large areas of active research attempting to automate the process of determining compliance requirements from source documents. Until artificial intelligence has solved this challenge and put everyone out of work, the analysis must be performed by hand.
When looking at a potential BNS, ask yourself the following:
- Does it regulate a business activity that can be automated by IT?
- Does it relate directly to the confidentiality, integrity, or availability of information or a business process?
- Can it be mapped to a security control in the control catalogue?
Below are examples of proposed BNSs:
| Proposed BNS | Pass/Fail | Rationale |
| The integrity of personal information shall be established and maintained. | Pass | - Relates to an activity that could be automated
- Relates to integrity - Can be mapped to specific controls |
| The department's IT systems must be secure and reliable. | Fail | - This statement does not relate to a specific business activity that could be automated by IT
- Does not relate specifically to confidentiality, integrity, or availability - It cannot be mapped to one or more specific security controls |
| The department will integrate IT security into project management. | Fail | - This statement is a security approach rather than a BNS
- It cannot be mapped to one or more specific security controls |
| Enemy force disposition must be available to all forward observation bases. | Pass | - Disposition information could be automated
- It relates to availability of information - It can be mapped to specific security controls |
| The department must protect the confidentiality of the information it stores | Fail | - This statement does not relate to a specific business activity that could be automated by IT
- It relates to confidentiality - It could be mapped to most security controls |
Avoid rabbit holes! Do not elicit BNSs where they don't exist. Clearly stated BNSs will often include the following words:
| Keywords for BNS |
| Confidential, confidentiality |
| Private, privacy |
| Integrity, accuracy |
| Available, availability, timely, continuous, downtime, accessible, access controlled |
| Identification, authentication, accountable, auditable |
Sometimes BNSs may be less clearly stated by the author(s) of the source document (but that does not mean they are not BNSs).
Statements may contain words such as the ones listed below:
| More Keywords for BNS |
| Approve |
| Assure, ensure |
| Legal, compliant |
| Anonymous |
| Admissible |
The BNS "Type" field can be used as a cue to help identify BNSs within the source document. The BNS Type field contains a dropdown whose list items are sourced from the Business Attributes tab in the BNS tool. In this tab, each BNS type is mapped to a category, its SABSA definition, and an example.
Some BNSs are associated directly with basic security properties (confidentiality, integrity, availability). Some BNSs are associated with typical security services (e.g. identification, authorization, etc.). Some BNSs are best described as a composite of security properties and services.
For more information, please read the Business Needs for Security Tool document and Excel spreadsheet.
