CYBER ENGINEERING PRINCIPLES
Patrick, Thanks for your feedback. Good point. I suggest that we amend principles 3 and 6 as follows:
3. Undertake continuous threat and vulnerability modelling, to understand emerging security risks, to inform and build in physical and logical security measures that are readily evolvable to incorporate new technologies, changes to threats, user needs and assessed risks.
6. Undertake analysis of both functional and non-functional requirements (e.g. performance, confidentiality, integrity, availability, safety, human factors) to understand priorities and trade-offs of stakeholder needs and document decision trade-offs. Safety and security are addressed as co-ordinated views when determining trade-offs. Stakeholder needs include system intended capability outcomes, economic and organisational needs, customer requirements, regulatory requirements and risk appetite.
Hi all, excited to see some conversation in here. I think this is a comprehensive set of principles.
For item 17. I think support and maintenance should include the need to test the appropriateness of controls once it is in operation. As an engineer I focus a lot of my effort in the design, validation and verification. However with IT systems, sometimes things can just stop working whilst they are in operation due to various external factors.
This can be huge burden on organisations if we test everything, so it is important to apply a risk-based decision-making framework to prioritise where the most likely attack surfaces are and test those controls are appropriate on regular basis (i.e. penetration testing).
This is a solid piece of work. I would say though that 17 principles sound like a long list - it is difficult to remember so many items. Have there been any thoughts about how those 17 principles could be structured or grouped to ease their understanding?
Principles 1 and 2 appear to be "core" statements and not limited to cyber only, just normal engineering practices. Could they be combined? Principle 1 says basically that a systematic approach should be applied and then generally this is achieved through deployment of a management system. Principle 2 somehow seem to limit the scope of management systems to a RASCI. Can we frame principle 1 as follows? Can it be trimmed down?
"Implement an engineering management system linked to the enterprise governance framework. The management system should provide for clear accountability, authority and responsibility for secure design, operation, maintenance, and disposal of the system. It should take a whole of system whole of lifecycle approach to secure design, operation, maintenance and disposal. The whole system includes all technology, people and processes. Technology includes all hardware, firmware and software and interconnected systems; people includes human interactions, human behaviour, and skills to operate and maintain the systems; and processes includes in built controls and processes required to operate and maintain the system securely.".
I feel that principle 5 is redundant. As engineers we use a multitude of standards, practices, manuals, principles and it is impossible to do the work without appreciation of the fact that principles should be used selectively based on the context on the system.
I feel that principle 15 is redundant as well since principle 17 requires to implement regimes for patching.
Second statement (plan for components obsolescence) in principle 17 seems redundant since the first statement already calls for having an obsolescence management.
These 17 principles are comprehensive perhaps too much so with some redundancy. My major concern is the lack of any discussion about trust - for any changes or additions to systems, for any transient or permanent interfacing and for interacting with the wide, wide world. Trust is a concept that needs to be described in terms of what it is, what it implies, how we judge or even measure trust and how we accumulate a degree of trust such that we can rely implicitly on a lower level of threat from the trusted entity, noting the threat is never zero.
I don't profess any special insight or competence in this field, but I am utterly convinced in its importance and hence would like the topic of trust to be widely addressed.
How do these principles relate to existing principles in the ISO2700x suite? Are they meant to be a replacement?
As the environments in which systems operate are always in a state of flux, should the principles include a statement about how systems will respond to this ongoing change, especially the risk of the unknown or unforeseen?
Doug, I a not sure that I understand the principles that you are referring to can you please let me know.
They are not meant to be a replacement but an addendum. The 2700x series focuses on design and development while the NIST/OWASP frameworks focus on making the design process secure. It is part of the whole shift-left ideology but this has changed over time and now with the introduction of AI the system is meant to change significantly. If you want some guidance, the OWASP SAMM project has a bunch of very useful blog post. If you want to discuss in more detail, I am happy to help.
I agree with much of what you have said but I would like to understand more about your statement that the ISO2700x series focusses on design and development. I understand that the ISO 27002 controls cover all phases of the NIST CSF framework including Detect, Respond and Recover which only occur after a system is deployed. Also, domains such as identity and access management and security assurance are usually considered to be operational activities.
Right you are, I have totally forgotten about the 27002, to be honest, I have not read that 27002, but I have talked to people who have and they seem to think it is an excellent standard. I personally prefer OWASP SAMM over the NIST standards. I find NIST very confusing, but OWASP standards are usually straightforward, easy to implement and fit perfectly with System Engineering practices. Again that is my view of these and please note I have not read 27002.
Thanks for the list of principles Shireane.
I have a question re the title of this area, basically, in "Cyber Engineering" is "Cyber" shorthand for "Cybersecurity" or "Cybersystems"?
The following article suggests "cyber" is about more than just security, and concerns a whole of systems approach to design of (secure) cyber systems. https://createdigital.org.au/cyber-engineering-new-way-of-thinking/
If that's the case, then I believe it would be helpful to use the more specific (though wider) title of "Cybersystems" Engineering.
Much of modern engineering is about systems, so to some extent the "systems" is redundant, however I see "cyber" being used in many places in the narrow sense of security in cyber systems.
I have to admit that I had assumed "cyber" was short for "cybersecurity" but that could very well be because of my own work experience and I just hadn't considered other options. The article you mention states that "Essentially, cyber engineering is about building cyber security into engineering designs right from the beginning.". Therefore I would consider cybersecurity to be a property of a system that has been designed and built according to cyber engineering principles. As you have stated, much engineering involves systems so what is the distinction between cyber systems and non-cyber systems? Is it the amount of electronic processing functionality?
While we're on the topic of definitions we can also consider the difference between "cybersecurity" and "information security", with the latter including non technical aspects such as operational processes, physical security (of more than just the cyber system) and user training. We should probably not try to encompass all of information security (at least not right now) as it is a broader topic.
I come from an Operational Technology environment with a control systems background and have worked in cyber for several years. I only just joined EA and saw this community.
We follow IEC 62443, but there are some common principles I don't see in the list above. What about common cyber security principles such as least privilege, need to know, separation of duties, defense in depth, zero trust?
I also think the proposed list of principles is quite long. Maybe some can be subpoints to principle 1?
Does Principle 1 cover acquisition of systems/assets/services under design? Security needs to be requested upfront in business requirements, contracts, SLAs for aquired systems/assets/services. We should be requesting systems/assets with security design in and not bolted on. Also it's important to have people cyber aware and competent in cyber security, not just have skills to operate and maintain systems.
Principle 8 doesn't seem directly related to cyber security.
Could we add "secure access control" to principal 17?
Third party risk management is also crucial in cyber security. I'm assuming principle 13 is covering some of this.
Some food for thought.
I originally put a submission forward with a group for cyber risk for the Energy industry in 2018, which was later adopted/exploited by AEMO. The understanding of "Consequences" outside of engineering is not well understood.
There is quite a lot of information on CIS and others.
Robert Relf 0408 999768
This is excellent, it may be useful to explicitly call out consideration of environmental impacts (a key part of a risk management framework) in item 6.