· web viewdemonstrate that layered zones are employed to protect information and information...

<Application Name and Release Number>

Security Threat and Risk Assessment (STRA)

12/17/2018

/tt/file_convert/5f9d5250a5623139e034f57c/document.docx 1

IDIM STRA<Service/App Name>

Security Threat and Risk Assessment

REFERENCE #:<Enter reference number from CITZ IMB>

Table of ContentsIntroduction.................................................................................................................................................. 3

Contacts...................................................................................................................................................... 3

Document Version Control........................................................................................................................... 3

Executive Summary..................................................................................................................................... 4

Risks Identified (Rated as “High” within the STRA)..................................................................................4

Action Items Identified.............................................................................................................................. 4

Recommendations Identified.................................................................................................................... 4

Signatures................................................................................................................................................... 5

Business Owner Acceptance of Risk.......................................................................................................5

Application/System/Service Description......................................................................................................6

Scope of This Assessment.......................................................................................................................... 6

Related Assessments.................................................................................................................................. 6

Information Description and Classification...................................................................................................6

Critical System Classification....................................................................................................................... 6

Criticality...................................................................................................................................................... 6

Reference................................................................................................................................................ 6

Technical and Security Architecture............................................................................................................7

Assessment................................................................................................................................................. 8

Key STRA Control Areas Checklist Requirements...................................................................................8

Key STRA Control Areas Checklist..............................................................................................................9

Risks and Recommendations....................................................................................................................12

Supporting Documentation........................................................................................................................13

Appendix A - Recommended Tests...........................................................................................................14



IntroductionThis Security Assessment is undertaken to provide guidance on the secure implementation and operation of a service, application or infrastructure. The assessment evaluates the impact of a loss of confidentiality, integrity and availability to the information that is collected, used and disclosed; and provides analysis of the technology and security controls deployed to help identify any security gaps and improvements.

ContactsApplication/System/ServiceMinistryDivisionBranch/SectionSystem OwnerSystem CustodianTechnical LeadSecurity Analyst

Document Version ControlVersion Date Change Reference Author1.0



Executive Summary

…

Risks Identified (Rated as “High” within the STRA)

1. ...2. …3. …

Action Items Identified

1. ...2. …3. …

Recommendations Identified

1. …2. …3. …



Signatures

The Security Threat and Risk Assessment and its recommendations are based on the best information available at the time of the assessment. By signing the Security Assessment, you acknowledge that this document has been completed to your satisfaction.

Application/System Owner(print name clearly)

(signature) Date

Garry MierzuakMinistry Information Security Officer(print name clearly)

(signature) Date

Chris HauffMCIO(print name clearly)

(signature) Date

Business Owner Acceptance of Risk

Sophia HowseExecutive Director(print name clearly)

(signature) Date

FOR OFFICE USE ONLYSigning below acknowledges receipt of the assessment. This marks the completion of the risk assessment.

Gary Perkins



Chief Information Security Officer (signature) Date



Application/System/Service Description…

Scope of This Assessment…

Related Assessments…

Information Description and Classification

Classification: <enter classification level>

References

BC Government Information Classification Framework

BC Government Information Classification Guidelines

Critical System Classification

<Enter critical system classification – use guide found below>

ReferencesCritical Systems Standard

Criticality

The criticality identifies the confidentiality, integrity and availability maturity level of a solution or system. The values below indicate the reported confidentiality, integrity and availability of this STRA’s system.

Loss of confidentiality <enter value>Loss of integrity <enter value>

Loss of availability – less than 1 hour <enter value>Loss of availability – half a day <enter value>Loss of availability – a day <enter value>Loss of availability – 2-3 days <enter value>Loss of availability – a week <enter value>Loss of availability – a month <enter value>

ReferencePossible Values and Harm for Confidentiality, Integrity and Availability


https://www2.gov.bc.ca/assets/gov/government/services-for-government-and-broader-public-sector/information-technology-services/standards-files/critical_systems_standard_v2_01.pdf

https://www2.gov.bc.ca/assets/gov/british-columbians-our-governments/services-policies-for-government/information-management-technology/information-security/classification-framework/iscguidelines.pdf

https://www2.gov.bc.ca/assets/gov/british-columbians-our-governments/services-policies-for-government/information-management-technology/information-security/classification-framework/iscframework.pdf


(Values: Extremely serious harm, Very serious harm, Serious harm, Minor harm & No significant harm)

<Examples of these harms/impacts>

Harm Table <Pick the level that is appropriate and delete the rest>

Financial harm, such as: Extremely significant loss of money or tangible assets Extremely significant penalties or recovery costs incurred Significant financial loss, penalty, or recovery expense Limited financial loss

Operational harm, such as: Severely impaired decision making, resulting in severe loss of program control Program closure or serious sanctions as a result of breach of legislation, contract or regulatory

standards Major political impact ‐ complete and extended loss of public trust of or confidence in government Significant impact on service levels Serious loss of confidence in a government program Damage to partnerships, relationships and reputation Staff forced to resign Limited impact on service levels Reduced staff effectiveness due to loss of morale

Personal harm, such as: Loss of life Extreme hazard to public safety Wide‐spread social hardship Major provincial economic hardship Serious personal hardship or embarrassment Minor embarrassment or inconvenience

Technical and Security Architecture…



Assessment

Key STRA Control Areas Checklist Requirements

Origin of the Key Control Areas QuestionsThe B.C. Government implemented government-wide information security policies. These policies are designed to enhance the security of government information systems and protect sensitive data that is in the government’s possession. The B.C. Government’s Information Security Policy (ISP) is modelled on the standard ISO 27002, which provides an internationally recognized framework for information security policies.

To validate whether information systems comply with the ISP, the government requires all new or changed information systems to go through an STRA process. This is a structured process that asks the information owner to identify the criticality of the information system, the harm that would be caused to the government if the information system was impacted by a security breach, and to confirm how well the information system conforms to the ISP. The latter part is accomplished by providing a list of requirements from the ISP and a set of recommendations for how to test compliance with each requirement; it is up to the information owner to assess and report their compliance.

The key controls provided in this document are a checklist of what the Provincial IDIM Program considers to be the most important controls from the security requirements as they relate to the ISP. In Appendix A there is a list of recommended tests relevant to each control area.

How to Respond to Each ControlComplete the current compliance status response column in Table 2 by a single number or letter as explained in Table 1 below. Evaluators should determine whether each item applies and, if so, record its compliance status. If genuinely not applicable, the item should be rated 'N'. Controls with weak scores will require a more detailed discussion with the IDIM team.

Status Response Option

Description

1 Controls have been tested and comply with the stated standard2 Controls comply with the stated standard3 Controls partially comply with the stated standard – more work is needed4 Controls do not comply with the stated standardN We believe that the stated standard does not apply in our caseX Current status is not known.

Table 1: Compliance Status Response Options



Key STRA Control Areas ChecklistPlease provide the CURRENT COMPLIANCE STATUS from your STRA scorecard assessment for each item in Table 2. Information provided will be held in strict confidence and will be used for the purpose of integration with the BC Services Card Authentication Service.

Item# Control Area Required Practice

Current ComplianceStatus(1-4, N, X)

☐ 1 Segregation of duties Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization's assets.

☐ 2 Information security awareness, education and training

All employees of the organization and, where relevant, contractors should receive appropriate awareness education and training and regular updates in organizational policies and procedures, as relevant for their job function.

☐ 3 Inventory of assets Assets associated with information and information processing facilities should be identified and an inventory of these assets should be drawn up and maintained.

☐ 4 Classification of information

Information should be classified in terms of legal requirements, value, criticality and sensitivity to unauthorised disclosure or modification.

☐ 5 Access control policy An access control policy should be established, documented and reviewed based on business and information security requirements.

☐ 6 Access control to program source code

Access to program source code should be restricted.

☐ 7 Policy on the use of cryptographic controls

A policy on the use of cryptographic controls for protection of information should be developed and implemented.

☐ 8 Physical entry controls Secure areas should be protected by appropriate entry controls to ensure that only authorized personnel are allowed access.

☐ 9 Separation of development, testing and operational environments

Development, testing, and operational environments should be separated to reduce the risks of unauthorized access or changes to the operational environment.





☐ 10 Controls against malware

Detection, prevention and recovery controls to protect against malware should be implemented, combined with appropriate user awareness.

☐ 11 Event Logging Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed.

☐ 12 Management of technical vulnerabilities

Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.

☐ 13 Segregation in networks Groups of information services, users and information systems should be segregated on networks.

☐ 14 Secure development policy

Rules for the development of software and systems should be established and applied to developments within the organization.

☐ 15 Technical review of applications after operating platform changes

When operating platforms are changed, business critical applications should be reviewed and tested to ensure there is no adverse impact on organizational operations or security.

☐ 16 Secure system engineering principles

Principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation efforts.

☐ 17 Secure development environment

Organizations should establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle.

☐ 18 Outsourced development

The organization should supervise and monitor the activity of out-sourced system development.

☐ 19 System security testing Testing of security functionality should be carried out during development.





☐ 20 Response to information security incidents

Information security incidents should be responded to in accordance with the documented procedures. (A Government-wide procedure exists for incident response).

☐ 21 Implementing information security continuity

The organization should establish, document, implement and maintain processes, procedures and controls to ensure the required level of continuity for information security during an adverse situation.

☐ 22 Privacy and protection of personally identifiable information

Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation where applicable.

☐ 23 Independent review of information security

The organization's approach to managing information security and its implementation (i.e. control objectives, controls, policies, processes and procedures for information security) should be reviewed independently at planned intervals or when significant changes occur.

Table 2: Key STRA Control Areas Checklist


Risks and Recommendations

Risk # Risk Description Risk Impact Risk Rating Recommendation<Describe the risk> <What is the impact of the risk> <High, Medium or Low) <What is the recommendation to deal with

the risk>R1 R2 R3 R4 R5 R6 R7 R8 R9 R10

Table 3: Risks and Recommendations


Supporting DocumentationTitle Description File PathDevelopment Team Threat ModelArchitecture Documentation


IDIM STRA

Appendix A - Recommended Tests

Item# Control Area Recommended Tests

1 Segregation of duties Demonstrate access analysis that privileged users controls are limited to job requirements.

Demonstrate job rotation to avoid sole control on key systems. Demonstrate no one person is responsible for the operation and

audit of critical systems. Demonstrate financial risk control reviews and / or independent

audits that demonstrate segregation of duties has been done 2 Information security

awareness, education and training

Demonstrate an information security awareness program is in place, is active, has wide participation.

Demonstrate that employees are delivered regular awareness education in their program areas of responsibility.

Demonstrate a review of information incidents where the results may indicate poor awareness training as the cause.

Demonstrate Executive level support for awareness training and education.

3 Inventory of assets Demonstrate that assets are identified and tracked throughout the asset's lifecycle.o creationo processingo storageo transmissiono deletiono destruction

Demonstrate the inventory of information assets is regularly inspected for correctness.

Demonstrate information assets are properly classified and the criticality of the asset is identified.

Demonstrate Executive support in asset management.4 Classification of

information Demonstrate that information applications and information

technology have STRAs completed that consider information classification.

Demonstrate that information owners / custodians apply classification to information and are accountable.

Demonstrate that information that is publicly identifiable information (PII) has PIA conducted.

Demonstrate that classified information is processed, handled, stored and transmitted according to information classification sensitivity.

Demonstrate that an injury or harm test is completed on information to determine proper classification.

Demonstrate that information security classification is applied across the Ministry.


IDIM STRA


5 Access control policy Demonstrate STRAs and PIAs have been completed. Demonstrate access default is "deny all." Demonstrate access is granted based on "least privileges." Demonstrate information sensitivity and classification is considered

prior to granting access. Demonstrate segregation of duties for authorizing, and

administering. Demonstrate review of access logs.6 Access control to

program source code Demonstrate that source code is not kept on production systems. Demonstrate that access to source code libraries is controlled and

logged (e.g. reports from software development tools on code check-in and check-out).

Demonstrate program source code is not stored separately from operation information systems.

Demonstrate program source code and program source libraries are managed according to established procedures.

Demonstrate that access to all program source libraries is logged and regularly reviewed.

7 Policy on the use of cryptographic controls

Demonstrate that the Ministry has completed a STRA on information systems to assess the risk identifying the quality and type of cryptographic controls required.

Demonstrate that the Ministry has considered the risk and types of encryption required for mobile devices.

Demonstrate that the Ministry applies cryptographic controls in protecting the confidentiality, integrity, non-repudiation and authentication of sensitive information.

8 Physical entry controls

Demonstrate that layered zones are employed to protect information and information processing facilities (e.g. reception zone, operation zone and security zone).

Demonstrate that access to restricted operational and security zones employs controls that identify, authenticate and monitor all access attempts.

Demonstrate that access controls and alarm systems have been implemented; active monitoring is performed with applicable log records retained.

Demonstrate regular entry controls testing to determine if they meet the requirements.

Demonstrate a STRA has been completed for all Restricted Operational and Security Zones.

Demonstrate access logs are reviewed for accuracy and


IDIM STRA


9 Separation of development, testing and operational environments

Demonstrate architecture diagrams validate clear separation between Dev / Test / Prod systems.

Demonstrate change management records demonstrating the procedure for migration.

Demonstrate a STRA has been completed. Demonstrate that a PIA has been completed for all systems with

personal identifiable information. Demonstrate where exemptions for separation

between Dev /sites/ES/ Test / Prod systems has been authorized.10 Controls against

malware Demonstrate that Ministry managed devices have an up-to-date

anti-malware software solution in place and is operational. Demonstrate that Ministry staffs have been provided with

awareness training related to malicious code risks (e.g. phishing and water-holing techniques).

Demonstrate that users are prohibited from downloading, accessing, or otherwise utilizing unauthorized software.

Demonstrate the immediacy of patching procedures to known exploits.

Demonstrate BCP that considers recovery from malware attacks. Demonstrate an effective communication plan to prevent the

spread of malware.

11 Event Logging Demonstrate that information systems audit logs capture pertinent information required for investigations / inquiries (e.g. user ID, time, date etc.).

Demonstrate logs are retained and reviewed. Demonstrate logs alarms are properly monitored. Demonstrate that if logs are turned off a Security Threat and Risk

Assessment has been completed.12 Management of

technical vulnerabilities

Demonstrate identified roles and responsibilities are established for the coordination of vulnerability management.

Demonstrate active monitoring for vulnerabilities to information systems.

Demonstrate routine patching for known vulnerabilities. Demonstrate emergency procedures for high risk vulnerabilities

(e.g. Heart bleed, Shellshock). Demonstrate patches are well tested prior to implementation to

prove effectiveness and do not cause conditions that exasperate the situation.

Demonstrate active logging for all vulnerability patching. Demonstrate a priority patching criteria based on risk in order the

most critical applications and informational systems are addressed first.


IDIM STRA


13 Segregation in networks

Demonstrate critical business systems that process confidential / sensitive information are segregated.

Demonstrate technologies and techniques for network segregation have a STRA completed.

Demonstrate for networks with Personal Identifiable Information a Privacy Impact Assessment has been completed.

Demonstrate that access between networks is controlled using a gateway.

Demonstrate wireless network services for sensitive environments are segregated from internal networks until access has passed through a gateway.

14 Secure development policy

Demonstrate security requirements in the design phase. Demonstrate security in version control. Demonstrate developer's capability in identifying

and addressing vulnerabilities. Demonstrate a security threat and risk assessment has been

completed. Demonstrate a privacy impact assessment has been completed for

all software that will process personal identifiable information.15 Technical review of

applications after operating platform changes

Demonstrate application control and integrity procedures to ensure that security has not been compromised by changes to the platform.

Demonstrate that notification of platform changes permit adequate time for appropriate testing prior to implementation.

Demonstrate the business continuity plan has been updated to reflect platform changes.

Demonstrate that a security threat and risk assessment has been completed.

Demonstrate platforms with personal identifiable information processing have a completed privacy impact assessment.

16 Secure system engineering principles

Demonstrate information systems engineering is based on security engineering principles, are documented and are applied.

Demonstrate that outsourced information systems apply security engineering principles in section G of the general service agreement.

Demonstrate new technologies are analyzed for security risks. Demonstrate new technology design is reviewed against known

attack patterns. Demonstrate a security threat and risk assessment is completed for

all information systems. Demonstrate a privacy impact assessment is completed for all

information systems containing personal identifiable information.


IDIM STRA


17 Secure development environment

Demonstrate that no personal identifiable information is used in the testing or development phases without a valid exemption from the Office of the Chief Information Officer.

Demonstrate that all applicable regulations and standards are considered in the development phase.

Demonstrate segregation between development, test and operational environments.

Demonstrate that security is considered throughout for each step of the system development lifecycle

Demonstrate personnel involved with the systems development are aware of system development security

18 Outsourced development

Demonstrate identification of ownership is identified in outsourcing software development.

Demonstrate that intellectual property rights are respected and managed through licensing agreements.

Demonstrate audit access is stipulated in procurement contracts. Demonstrate information system security is involved in every step

of outsourced development.19 System security

testing Demonstrate acceptance testing is segregated from development. Demonstrate all new and updated systems are tested prior to

implementation.20 Response to

information security incidents

Demonstrate there are documented procedures for information security response.

Demonstrate post incident analysis includes corrective recommendation measures.

21 Implementing information security continuity

Demonstrate a management structure is in place to mitigate and respond to adverse events.

Demonstrate documented plans, response and recovery procedures are developed and approved.

Demonstrate compensating controls for information security controls that cannot be maintained during an adverse situation.

22 Privacy and protection of personally identifiable information

Demonstrate Security Threat and Risk Assessments have been completed.

Demonstrate Privacy Impact Assessments have been completed. Demonstrate user awareness in dealing with Personal Identifiable

information.23 Independent review

of information security

Demonstrate a review of the information security program has been conducted by an independent third party.

Demonstrate authorization from the Information Owner is obtained prior to technical compliance testing.

Demonstrate the Chief Information Security Officer is notified prior to technical testing.

Demonstrate all results for technical testing are provided to the information Owners and the Chief Information Security Officer.

Table 4: Recommended Tests


· web viewdemonstrate that layered zones are employed to protect information and information...

Documents