Take the ISO 27001 course exam and get the EU GDPR course exam for free
LIMITED-TIME OFFER – VALID UNTIL SEPTEMBER 30, 2021
  • (0)
    ISO-27001-ISO-22301-blog

    ISO 27001 & ISO 22301 Blog

    What are secure engineering principles in ISO 27001:2013 control A.14.2.5?

    In my days of programming (big hosts and green/amber terminals, matrix printers…) we didn’t think so much about information security, and especially not about secure engineering. Functional specifications were very simple, and acceptance criteria for the final product were: it had to look fairly nice, calculations (if any) had to be correct, reports with few selection criteria worked quickly… and few others.

    Everything changed with PCs, and especially with the Internet.

    In shopping centers, banks, airports, hospitals, nuclear sites, etc. various types of computer programs, through various types of networks, are handling data, monitoring, and even managing processes. We can use a vast number of online services that are available globally and 24/7. It’s great – if we are all good guys (not too sloppy ones) and Mother Nature treats us nicely.

    Confidentiality, integrity, and availability (CIA) of information is mandatory, and that’s where secure engineering principles will help.


    Secure engineering and secure engineering principles

    Secure engineering is actually how you will apply security while developing your IT projects. In order to do that, you should take into account threats from natural disasters and humans. These may include: earthquakes, tornadoes, floods, misuse, and malicious human behavior (find more threats and vulnerabilities in Catalogue of threats & vulnerabilities.

    To assure management of those treats, high-level rules are defined to apply security. These are your secure engineering principles. For example, most of the projects deal with information. So, your principle will be “Assure information protection in processing, transit, and storage.” Based on principles, procedures will be developed that define activities in detail. For the mentioned example, you will define, e.g., a backup procedure and clearly state that incremental backup should be done every day, and full backup done during the weekend. Also, you will define responsibilities and how to control whether the procedure is followed.

    It’s important to know that principles apply to every phase of your development projects, and to all architectural layers of your final products (business, data, applications, and technology).

    ISO 27001 A.14.2.5 – What are secure engineering principles?

    Requirements of ISO 27001:2013 – control A.14.2.5

    To help you with the implementation of secure system engineering principles, a new control is introduced in Annex A: A.14.2.5 – Secure system engineering principles. Control is not defined with many details, but in general, ISO 27001 requires you to establish (i.e., define), document, apply (i.e., use them in real life), and regularly review your principles.

    As you can see, the standard is not very specific; so, in order to implement that control, you can start with addressing the biggest threats.

    So, you should introduce your principles to your people and make sure that they are followed. If you have outsourced partners, you should get them to apply those principles or to apply principles comparable to yours. You can do that by using contracts or some other regulatory means. If you are planning to use some new technologies, they should be analyzed for security risks (like known attack patterns).

    A few hints on how to approach

    Recently, I audited one ICT company (consulting, developing, implementations services) that defines secure principles in the most desirable way: easy to understand and operationally manageable.

    Due to the fact that control A.14.2.5 is applicable, they took an interesting approach. During several brainstorming sessions with key employees (from the legal department, account managers, system architects, developers, testers, consultants from the implementation team, help desk guys) secure engineering principles emerged. During those sessions, they analyzed their current situation and assessed the biggest threats during development of their ICT projects, grouped them, and defined an approach of how to manage them. Of course, the detailed approach was defined in procedures and work instructions. To gain a customer view, on their last session they brought in the CIO of their biggest customer.

    To test the defined principles (it was really testing of the procedures and templates defined) they documented an “internal audit” for one old application, using quality assurance checklists for each development stage.

    So, since security engineering principles (a document with “political” statements) are your guidelines for building information security into all architectural layers, in order to have them implemented in a real-world environment they have to be followed by a procedure that is easily understandable by all affected people. If we take the previously mentioned principle “Assure information protection in processing, transit, and storage” and apply it to application development, it would be as follows:

    • business layer – e.g., based on user authentication level; only particular users can see personal data
    • data layer – e.g., only logging in with a strong database password for database maintenance activities is allowed
    • applications – e.g., application encryption is used for data export and import
    • technology – e.g., open-source software and state-of-the-art hardware and network infrastructure provided by selected vendors are used

    Measure, Measure, Measure, Cut – M3C1 (Measure three times cut once)

    It’s difficult to create a cookbook on how to define secure engineering principles. It really depends on lots of different factors, and it’s different for each company. Maybe the most important thing is that they are understandable for your employees and that everybody in the cycle gets “something for themselves.”

    Prior to final approval of your documentation that defines secure engineering principles, try to apply it to some existing or old project to make sure that added value can be achieved. Don’t rush with it – define something that will help you and assure added value for your customer.
    So, before you approve your principles – Measure, Measure, Measure and then Cut.

    To learn how to become compliant with every clause and control from Annex A and get all the required policies and procedures for controls and clauses, sign up for a 30-day free trial of Conformio, the leading ISO 27001 compliance software.