The requirements for product safety cannot be excluded even if there are no safety issues related to the product. If you are not designing the product and get the drawing from the third party (e.g. customer), they should provide you with information on the product safety. If they don't, you should conduct risk assessment to determine if there are any risks related to the product safety and take appropriate actions. Even if there are no product safety issues, you will still need to have the product safety process.
Thanks for taking time from your busy schedule to reply to me.
Answer: ISO 27001 does not prescribe any solution to be applied for security controls in Annex A, only objectives to be achieved. This gives organizations freedom to implement the most adequate solutions according to their context. For guidelines and recommendations about what to consider in the implementation of security controls, you should consider the ISO 27002 standard.
That said, regarding security of system passwords, service passwords, and application passwords, including passwords at administrator level, you should consider ISO 27002 recommendations for the following controls:
- Control A.9.2.3 (Management of privileged access rights): for shared administration user IDs, you should consider practices like changing passwords frequently and as soon as possible when a privileged one user of these shared IDs leaves or changes job, and communicating these passwords to administrators through secure mechanisms. Besides that, all other recommendations from control A.9.3.1 (Use of secret authentication information), aimed for general users, should also be applicable to administrators.
- Control A.9.3.1 (Use of secret authentication information): when passwords need to be part of automated log on procedures they must be properly protected (e.g., do not store password on plain text)
- Control 9.4.3 (Password management system): when stored, password should be kept on files separated from application system data.
We want to start the risk assessment right before the design stage.
We want to ensure that the design is secure and taking into consideration all the security risks that system environment will be facing.
By understanding the risk and the risk level, all appropriate controls will be put in place at the design stage.
This will then ensure secure development, secure delivery and the end objective to have secure operation and maintenance.
I am thinking of using threat modelling risk assessment at the design stage.
As I understand the risk assessment is not a “one time do and forget” exercise. Thus, we should be having a periodic risk assessment, with review and monitoring. May be it is a good practice to have a yearly exercise.
For our environment, we should have it at every stages.
Hope to get some feedback from you on the above.
Answer: Your thinking is absolutely right. System security must be though as soon as possible in the development process, and s hould be periodically reviewed because of the identification of new types of threats, codification problems and opportunities of improvement. To ensure this thinking is considered in your organization's process you should consider the implementation of a Secure Development Policy (a template for this policy is included in your toolkit, at folder 08 Annex A, subfolder A.14 System acquisition, development and maintenance), as well as integrate the security activities in your current development process. A good reference for secure development is the ISO 15408 standard, which you can see at this link: https://www.iso.org/standard/50341.html
The first thing you have to consider is the identification of the requirements this Information Security Policy must comply to (e.g., laws, contracts, standards, etc.), then, based on these requirements you can plan what to look for as evidences that this policy is implemented and being followed.
This toolkit has four documents (Internal Audit Checklist, Procedure for Internal Audit, Annual Internal Audit Program, and Internal Audit Report) that can help you perform an internal audit considering the ISO 27001, the leading ISO standard for information security, in a easy and efficient way.
These articles will provide you further explanation about internal audit:
- How to prepare for an ISO 27001 internal audit https://advisera.com/27001academy/blog/2016/07/11/how-to-prepare-for-an-iso-27001-internal-audit/
- How to make an Internal Audit checklist for ISO 27001 / ISO 22301 h ttps://advisera.com/27001academy/knowledgebase/how-to-make-an-internal-audit-checklist-for-iso-27001-iso-22301/
On the other side, defects relate to not satisfying service requirements and involve e.g. change on the service in early life support phase. According to ITIL, definition of a problem is " A cause of one or more incidents.". So, if that defect doesn't cause incidents, there is no need to go to problem management. It's rather that you need to send it back to development (Release and Deployment or even to Service Design processes if you conclude that there is an error in service design). So, as you could see, defect can have much deeper causes then "usual relation" incident -problem.
Major Incident Management process
Answer:
I assume MIM stands for Major Incident Management. So, having so many people in MIM process is seldom productive. MIM usually involves minimum required people. That means you should have someone who is in charge per resolution (consider it as "project leader"), someone from top management (you need quick reaction, best people you have, maybe some monetary resources - so you need strong sponsor) and technical experts related to the topic.
La organización debe controlar la identificación única de los productos cuando la trazabilidad es un requisito, y debe retener la información documentada necesaria para permitir la trazabilidad. Esto significa que va a necesitar proporcionar justificaciones para las exclusiones que realice
Respecto a la cláusula 8.5.2, no todos los productos o servicios requieren identificación y trazabilidad. Algunas empresas etiquetan sus piezas con números de serie únicos que pueden contener todos los datos de la trazabilidad de esa pieza, mientras otros aplican la trazabilidad al lote que se necesita.
Lo que se certifican son las actividades, que coinciden con el alcance de la certificación. En el caso de que quieras implementar ISO 9001 en un solo departamento/unidad de la organización/localización, no existen demasiados beneficios, ya que la norma ISO 9001 ha sido desarrolla para ser aplicada en la totalidad de la organización, por lo que contiene requisitos para toda la organización.
ISO 22301 toolkit content relate to internal and external issues
Answer: The information required by ISO 22301 clause 4.1 is addressed by following templates:
- Organization's activities (from clause 4.1 a)) and potential impact from disruptive incidents are addressed by template Business Impact Analysis Questionnaire (located at folder 04 Business Impact Analysis Methodology)
- Organization's functions (from clause 4.1 a)) are addressed in all templates when an activity to be performed is required (by means of the field [job title]). Functions related specifically to the BCMS are defined in the template Business Continuity Policy, section 3.5, (located at folder 03 Business Continuity Policy)
- Organization's product and services (from clause 4.1 a)) are addressed by template Business Continuity Policy, section 3.5, (located at folder 03 Business Continuity Policy)
- Relations with suppliers, partners and interested parties (from clause 4.1 a)) are addressed by template Business Continuity Strategy (located at folder 05 Business Continuity Strategy)
- Relationships between the Business Continuity Policy and other organization's policies, objectives and general risk management strategy (from clause 4.1 b)) are addressed by template Business Continuity Policy, section 2, (located at folder 03 Business Continuity Policy)
- Organization's risk appetite (from clause 4.1 c)) is addressed by template Business Impact Analysis Questionnaire, section 6 (maximum acceptable outage) (located at folder 04 Business Impact Analysis Methodology)